Re: git diff woes

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Tue, 13 Nov 2007, Andreas Ericsson wrote:

> Junio C Hamano wrote:
> > Andreas Ericsson <ae@op5.se> writes:
> > 
> > > In the check_ntpd.c program, there is no bug. I found the git diff 
> > > output surprising, so I reported it.
> > 
> > This is what I get from "GNU diff -pu" which makes me surpried
> > that anybody finds "git diff" hunk header surprising.  Notice
> > that hunk at line 84.
> > 
> > --- read-cache.c	2007-11-12 12:08:00.000000000 -0800
> > +++ read-cache.c+	2007-11-12 12:07:54.000000000 -0800
> > @@ -60,7 +60,7 @@ static int ce_compare_data(struct cache_
> >  	return match;
> >  }
> >  -static int ce_compare_link(struct cache_entry *ce, size_t expected_size)
> > +static int ce_compare_lonk(struct cache_entry *ce, size_t expected_size)
> >  {
> >  	int match = -1;
> >  	char *target;
> > @@ -84,7 +84,7 @@ static int ce_compare_link(struct cache_
> >  		match = memcmp(buffer, target, size);
> >  	free(buffer);
> >  	free(target);
> > -	return match;
> > +	return match + 0;
> >  }
> >   static int ce_compare_gitlink(struct cache_entry *ce)
> 
> 
> I notice it, and I don't like it. I guess I'm just used to git being
> smarter than their GNU tool equivalents, especially since it only ever
> applies patches in full.

I still think the existing behaviour is reasonable.  When I read a diff 
(and remember, the hunk headers are _only_ there for the reviewer's 
pleasure), the function names are a hint for _me_ where to look, and which 
is the context, in my existing, _original_ file.

That is, unless I have already applied the patch, and am looking for the 
reverse patch.  And, lo and behold, the reverse patch generated by 
git-diff really shows the now-current function name!

So IMO "fixing" this behaviour would be a regression.

Ciao,
Dscho