Re: git full diff output issues..

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 5, 2005, 15:11 UTC
Message-ID: <Pine.LNX.4.58.0506050806400.1876@ppc970.osdl.org>
In-Reply-To: <7vu0kd42dm.fsf@assigned-by-dhcp.cox.net>

On Sun, 5 Jun 2005, Junio C Hamano wrote:

> 
> The case you mentioned (i.e. /dev/null) is fine but rename/copy
> is "broken" according to the definition by git-apply.

No problem, the renames always get the names from the "rename" line, not the header. Same goes for copies.

It's only modified files that keep the same name _and_ the same content that don't have the name uniquely on a line somewhere.

Show 12 quoted lines

> What do you want the diff-patch format to say for this one?
> 
>     :100644 100644 SHA1-OLD SHA1-NEW R frotz.c nitfol.c
> 
> Currently I am saying:
> 
>     diff --git a/frotz.c b/nitfol.c
>     similarity index 89%
>     rename old frotz.c
>     rename new nitfol.c
>     --- a/frotz.c
>     +++ b/nitfol.c

This finds the old names unambiguously in _two_ places: in the "--- " line (no question about where it begins: it's -p1, or where it ends - at the newline) _and_ on the "rename old xxxx" line.

The only case that was special was literally the "same name, no content changes, new mode" case, which looked like

	diff --git a/oldname.c b/oldname.c
	new mode 100755
	old mode 100644

and thus _only_ had the name in the (normally ambiguous wrt whitepsace) header line.

But by having the requirement that the format of the header line for that case is "-p1" together with both names being the same, it's not ambigious any more.

		Linus