From: Linus Torvalds Date: Tue, 17 May 2005 15:20:26 GMT Subject: Re: [PATCH 2/4] Tweak diff output further to make it a bit less distracting. Message-ID: In-Reply-To: <20050517070158.GA10031@pasky.ji.cz> On Tue, 17 May 2005, Petr Baudis wrote: > > > > 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