From: Linus Torvalds Date: Sun, 05 Jun 2005 15:11:02 GMT Subject: Re: git full diff output issues.. Message-ID: 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. > 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