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

From: Petr Baudis <pasky@ucw.cz>
Date: May 17, 2005, 07:01 UTC
Message-ID: <20050517070158.GA10031@pasky.ji.cz>
In-Reply-To: <Pine.LNX.4.58.0505161556260.18337@ppc970.osdl.org>

Dear diary, on Tue, May 17, 2005 at 01:28:31AM CEST, I got a letter where Linus Torvalds <torvalds@osdl.org> told me that...

Show 13 quoted lines

> 
> 
> On Mon, 16 May 2005, Junio C Hamano wrote:
> 
> >     # mode: 100644 100755 nitfol
> >     --- a/nitfol
> >     +++ b/nitfol
> 
> >     @. 100644 100755 nitfol
> >     --- a/nitfol
> >     +++ b/nitfol
> 
> I have to say, I muct prefer the first over the second.

Glad. :-)

Show 22 quoted lines

> One final note: I actually think that "rename patches" make a ton of 
> sense, even if git itself doesn't track renames. If we ever have a "smart 
> diff" thing that can generate inter-file diffs, I'd like to eventually see
> 
> 	diff -git a/kernel/sched.c b/kernel/sched.c.old
> 	rename kernel/sched.c kernel/sched.c.old
> 	old mode 100644
> 	new mode 100755
> 	--- a/kernel/sched.c
> 	+++ b/kernel/sched.c.old
> 	@@ -1,5 +1,5 @@
> 	 /*
> 	- *  kernel/sched.c
> 	+ *  kernel/sched.c.old
> 	  *
> 	  *  Kernel scheduler and related syscalls
> 	  *
> 
> Notice? We could have a mode change, a rename _and_ a content change, all
> at the same time under the same header. That's obviously a totally idiotic
> example, but the point is that if we have a nice "extended diff header"
> setup, the format is very easily able to accomodate things like this.

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?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor