threads / bug / 1481

git reveals a bug in (some versions) BSD diff

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

## tl;dr

4 messages between Aug 12, 2005 and Aug 12, 2005.

replies: 3people: 2as markdown or json

Johannes Schindelin· Aug 12, 2005, 12:32 UTC · lore

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

Junio C Hamano· Aug 12, 2005, 15:46 UTC · re: Johannes Schindelin · lore

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

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

Show 6 quoted lines

> 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.

Johannes Schindelin· Aug 12, 2005, 16:04 UTC · re: Junio C Hamano · lore

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

Hi,

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

Show 16 quoted lines

> 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.

Junio C Hamano· Aug 12, 2005, 16:30 UTC · re: Johannes Schindelin · lore

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

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?