Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-17 Thread Junio C Hamano
Johannes Sixt writes: > diff --git a/compat/mingw.c b/compat/mingw.c > index afc892d..4e63838 100644 > --- a/compat/mingw.c > +++ b/compat/mingw.c > @@ -335,6 +335,28 @@ FILE *mingw_freopen (const char *filename, const char > *otype, FILE *stream) > return freopen(filename, otype, stream);

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-17 Thread Johannes Sixt
Am 10/16/2012 8:39, schrieb Johannes Sixt: > Am 10/15/2012 18:54, schrieb Junio C Hamano: >> Ideally, that earlier workaround >> should have done a logica equivalent of: >> ... >> and did so not in-line at the calling site but in a compat/ wrapper >> for fflush() to eliminate the need for the ifdef

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-15 Thread Johannes Sixt
Am 10/15/2012 18:54, schrieb Junio C Hamano: > Ideally, that earlier workaround > should have done a logica equivalent of: > ... > and did so not in-line at the calling site but in a compat/ wrapper > for fflush() to eliminate the need for the ifdef. Fair enough. >> But reverting the EINVAL check

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-15 Thread Junio C Hamano
Johannes Sixt writes: > For fflush() (as in write_or_die.c), EINVAL is not even listed > as possible error code. Therefore, catching EINVAL wholesale should not be > a problem, IMO, at least not "on other systems". I see a disturbing gap between "EINVAL is not supposed to be even possible" and "

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-14 Thread Johannes Sixt
Am 10/14/2012 6:29, schrieb Junio C Hamano: > Johannes Sixt writes: > >> It might be worth it. We already have a similar special case in >> write_or_die.c:maybe_flush_or_die() for Windows, although it is not about >> a colon in a path name. >> >> Perhaps like this. > > Hrm, the "we already have"

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-13 Thread Junio C Hamano
Johannes Sixt writes: > It might be worth it. We already have a similar special case in > write_or_die.c:maybe_flush_or_die() for Windows, although it is not about > a colon in a path name. > > Perhaps like this. Hrm, the "we already have" one b2f5e26 (Windows: Work around an oddity when a pipe

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-12 Thread Johannes Sixt
Am 10/11/2012 17:51, schrieb Junio C Hamano: > Johannes Sixt writes: > >> I saw EINVAL errors when 'git grep pattern rev' was run on Windows. The >> reason is that the code attempted to access "rev:dir/.gitattributes" in >> the worktree, which is an invalid path on Windows due to the colon. The >

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-11 Thread Junio C Hamano
Johannes Sixt writes: > I saw EINVAL errors when 'git grep pattern rev' was run on Windows. The > reason is that the code attempted to access "rev:dir/.gitattributes" in > the worktree, which is an invalid path on Windows due to the colon. The > lack of this warning indicates that the attempts to

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-10 Thread Johannes Sixt
Am 10/10/2012 21:56, schrieb Junio C Hamano: > Johannes Sixt writes: > >> At any rate, I don't observe the warnings anymore with this series. > > What kind of warnings have you been getting? Earlier we had a bug > in the jk/config-warn-on-inaccessible-paths series that made it warn > when we tr

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-10 Thread Junio C Hamano
Nguyen Thai Ngoc Duy writes: > On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt wrote: >>> + git commit -m new && >>> + echo "Binary file HEAD:t matches" >expect && >>> + git grep text HEAD -- t >actual && >>> + test_cmp expect actual && >>> + git reset HEAD^ >>> +' >> >> And i

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-10 Thread Nguyen Thai Ngoc Duy
On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt wrote: >> + git commit -m new && >> + echo "Binary file HEAD:t matches" >expect && >> + git grep text HEAD -- t >actual && >> + test_cmp expect actual && >> + git reset HEAD^ >> +' > > And in yet another test, should > > gi

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-10 Thread Junio C Hamano
Johannes Sixt writes: > At any rate, I don't observe the warnings anymore with this series. What kind of warnings have you been getting? Earlier we had a bug in the jk/config-warn-on-inaccessible-paths series that made it warn when we tried to open a .gitattribute file and open() returned an er

Re: [PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-10 Thread Johannes Sixt
Am 10/10/2012 15:59, schrieb Nguyễn Thái Ngọc Duy: > This patch passes real paths down to grep_source_load_driver(). Except > grepping a blob, all other cases should have right paths down to ... grepping a blob or tree object... > grep_source_load_driver(). In other words, .gitattributes are stil

[PATCH v2 2/2] grep: stop looking at random places for .gitattributes

2012-10-10 Thread Nguyễn Thái Ngọc Duy
grep searches for .gitattributes using "name" field in struct grep_source but that field is not real on-disk path name. For example, "grep pattern rev" fills the field with "rev:path", which is non-existent usually until somebody exploits it to drive git away. This patch passes real paths down to