Re: [PATCH 2/4] Tweak diff output further to make it a bit less distracting.

From: Linus Torvalds <torvalds@osdl.org>
Date: May 17, 2005, 15:20 UTC
Message-ID: <Pine.LNX.4.58.0505170812060.18337@ppc970.osdl.org>
In-Reply-To: <20050517070158.GA10031@pasky.ji.cz>

On Tue, 17 May 2005, Petr Baudis wrote:

Show 7 quoted lines

> > 
> > 	diff -git a/kernel/sched.c b/kernel/sched.c.old
> > 	rename kernel/sched.c kernel/sched.c.old
> 
> Actually, if the git diff format is fixed, do we even need the explicit
> rename line? It could be enough if the filenames on the diff line would
> be just different. Or you want it because of clarity?

Yes, it's something we can glean from the header itself (or the ---/+++ lines), but I'd prefer it just to make things really obvious. Especially as all the other pathnames involved (both on the "diff" header line and on the ---/+++ lines) are in non-canonical -p1 format. So the "rename" line would be the only one that is actually in canonical form.

There's also a real technical reason for this: since the rename format would not be a valid patch for a traditional "patch" program, and if we ever want to actually teach "patch" to handle it, we really need to be explicit. There are tons of traditional patches around that say

	diff -Nur a/kernel/sched.c.old b/kernel/sched.c
	--- a/kernel/sched.c.old
	+++ b/kernel/sched.c
	...

and clearly the above is _not_ a rename from "sched.c.old" to "sched.c", so if we want to teach "patch" about the magic git rules, we'd have to have something unambiguous that a GNU patch maintainer might be willing to trigger on. The combination of the "diff -git " and "rename" markers might be such a thing.

So it's a combination of clarity, canonical names, and "patch" issues.

		Linus