git reveals a bug in (some versions) BSD diff

git reveals a bug in (some versions) BSD diff

[Johannes Schindelin]

Hi,

big was my surprise when my daily routine of "git pull" && "make test" 
failed. "git bisect" revealed that commit 8e832e: "String comparison of 
test is done with '=', not '=='." was the culprit.

But it isn't. The version of diff present on my iBook (OS 10.2.8) does not 
work properly in this case:

	(echo a; echo b | tr -d '\012') >frotz.2
	(echo a; echo c; echo b | tr -d '\012') >frotz.3
	diff -u frotz.2 frotz.3

yields

	--- a1  2005-08-12 14:24:19.000000000 +0200
	+++ a2  2005-08-12 14:24:27.000000000 +0200
	@@ -1,2 +1,3 @@
	 a
	+c
	 b

Note the missing "\ No newline at end of file". The same happens on 
sourceforge's compile farm's OS 10.1 server, but not on its OS 10.2 
server.

How to go about that? Silently ignore the missing line in apply.c? Force 
users to update their diff to a sane version?

Ciao,
Dscho

Re: git reveals a bug in (some versions) BSD diff

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Note the missing "\ No newline at end of file". The same happens on 
> sourceforge's compile farm's OS 10.1 server, but not on its OS 10.2 
> server.
>
> How to go about that? Silently ignore the missing line in apply.c? Force 
> users to update their diff to a sane version?

Hmph.  We could tackle this two ways.  We probably _could_
special case the trailing newline case if this problem is
widespread, but a more general solution would be to teach
git-apply '--fuzz'.  On the other hand, we could configure to
use gdiff (or whatever GNU diff is called on those hosts with
broken diff command) at the build time.  Probably it would be
the bast to have an explicit option --fuzz to git-apply.

Re: git reveals a bug in (some versions) BSD diff

[Johannes Schindelin]

Hi,

On Fri, 12 Aug 2005, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Note the missing "\ No newline at end of file". The same happens on 
> > sourceforge's compile farm's OS 10.1 server, but not on its OS 10.2 
> > server.
> >
> > How to go about that? Silently ignore the missing line in apply.c? Force 
> > users to update their diff to a sane version?
> 
> Hmph.  We could tackle this two ways.  We probably _could_
> special case the trailing newline case if this problem is
> widespread, but a more general solution would be to teach
> git-apply '--fuzz'.  On the other hand, we could configure to
> use gdiff (or whatever GNU diff is called on those hosts with
> broken diff command) at the build time.  Probably it would be
> the bast to have an explicit option --fuzz to git-apply.

I'd prefer to deprecate that diff program by telling so in the test. 
Something along the lines "blabla. If this fails, chances are you have a 
borked diff. Try GNU diff..."

Ciao,
Dscho

BTW: On my system, gdiff does not exist.

Re: git reveals a bug in (some versions) BSD diff

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I'd prefer to deprecate that diff program by telling so in the test. 
> Something along the lines "blabla. If this fails, chances are you have a 
> borked diff. Try GNU diff..."

Wouldn't it give the people with broken diff a false impression
that their "git diff" actually produces a good result when it
does not?

Re: git reveals a bug in (some versions) BSD diff

[Brad Roberts]

I'm seeing this on a standard os/x 10.3.9 install which seems to have an
old, but still GNU based, diff.

$ which diff
/usr/bin/diff

$ diff --version
diff - GNU diffutils version 2.7

$ sh ./t4101-apply-nonl.sh
*   ok 1: apply diff between 0 and 1
*   ok 2: apply diff between 0 and 2
*   ok 3: apply diff between 0 and 3
*   ok 4: apply diff between 1 and 0
*   ok 5: apply diff between 1 and 2
*   ok 6: apply diff between 1 and 3
*   ok 7: apply diff between 2 and 0
*   ok 8: apply diff between 2 and 1
* FAIL 9: apply diff between 2 and 3
        git-apply <diff.2-3 && diff frotz.3 frotz
*   ok 10: apply diff between 3 and 0
*   ok 11: apply diff between 3 and 1
* FAIL 12: apply diff between 3 and 2
        git-apply <diff.3-2 && diff frotz.2 frotz
* failed 2 among 12 test(s)

For what it's worth, this is the only test failing on this box (after the
application of the TZ patch I just sent).

Later,
Brad

Re: git reveals a bug in (some versions) BSD diff

[Johannes Schindelin]

Hi,

On Sat, 13 Aug 2005, Brad Roberts wrote:

> I'm seeing this on a standard os/x 10.3.9 install which seems to have an
> old, but still GNU based, diff.
> 
> $ which diff
> /usr/bin/diff
> 
> $ diff --version
> diff - GNU diffutils version 2.7

That is exactly the same as with 10.2.8.

> [...] 
> * FAIL 9: apply diff between 2 and 3
>         git-apply <diff.2-3 && diff frotz.3 frotz
> * FAIL 12: apply diff between 3 and 2
>         git-apply <diff.3-2 && diff frotz.2 frotz

Yes, that is what I saw, too. Actually, I found the bug in diff-v2.7 
annoying enough that I updated (just diff) to version 2.8.1. That works 
fine.

Ciao,
Dscho