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 from
Am 10/14/2012 6:29, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net 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
Johannes Sixt j.s...@viscovery.net 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
Am 10/11/2012 17:51, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net 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
Johannes Sixt j.s...@viscovery.net 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
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
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 still
Johannes Sixt j.s...@viscovery.net 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
On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt j.s...@viscovery.net 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
git grep
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
On Wed, Oct 10, 2012 at 9:21 PM, Johannes Sixt j.s...@viscovery.net 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^
+'
Am 10/10/2012 21:56, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net 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
11 matches
Mail list logo