Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: [PATCH] Detect renames in diff family.

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:41:57


On Thu, 19 May 2005, Junio C Hamano wrote:
Special request for Linus is to check if I did not screw up the
various calls into the diff core from diff-tree.  Essentially
the idea is to start one patchset session with diff_setup() and
close it with diff_flush() before you start another patchset
session.
It all looks ok from a quick setup, and with this I can now do

	git-whatchanged -M

in the kernel, and searching for renames I find:

	diff --git a/arch/um/kernel/sys_call_table.c b/arch/um/sys-x86_64/sys_call_table.c
	rename old arch/um/kernel/sys_call_table.c
	rename new arch/um/sys-x86_64/sys_call_table.c
	--- a/arch/um/kernel/sys_call_table.c
	+++ b/arch/um/sys-x86_64/sys_call_table.c
	@@ -1,4 +1,4 @@
	-/* 
	+/*
	  * Copyright (C) 2000 Jeff Dike (jdike@karaya.com)
	  * Copyright 2003 PathScale, Inc.
	  * Licensed under the GPL
	@@ -14,6 +14,12 @@
	 #include "sysdep/syscalls.h"
	 #include "kern_util.h"
	 
	+#ifdef CONFIG_NFSD
	....

which looks quite correct.

I notice that you left some debugging output in there ("**score **" 
stuff), and I'll remove it, but it's merged and pushed out and passed my 
trivial tests. 

[ rambling mode on: ]

One thing that struck me is that there is nothing wrong with having the 
same old file marked twice for a rename, or considering new files to be 
copies of old files. So if we ever allow that, then "rename" may be the 
wrong name for this, since the logic certainly allows the old file to 
still exist (or be removed and show up multiple times in a new guise).

In other words, let's say that we create a new architecture or a new 
filesystem, and we have tons of _new_ files, but not a lot of removed 
files. It would literally be very cool to see that the new files are based 
on contents of old files, and that it would thus potentially be very 
interesting to see a diff like

	diff --git a/arch/i386/kernel/irq.c b/arch/x86-64/kernel/irq.c
	based-on old arch/i386/kernel/irq.c
	creates new arch/x86-64/kernel/irq.c
	--- arch/i386/kernel/irq.c
	+++ arch/x86_64/kernel/irq.c
	@@ -1,205 +1,31 @@
	 /*
	- *     linux/arch/i386/kernel/irq.c
	+ *     linux/arch/x86_64/kernel/irq.c
	  *
	  *     Copyright (C) 1992, 1998 Linus Torvalds, Ingo Molnar
	  *
	...

(the above is a made-up example, but it's at least _half-way_ valid).

I'm not suggesting you actually do this, if only because it's quite
expensive: it means that any newly added file would have to be compared
with _all_ files in the previous archive, which is just too damn
expensive. But I'd like people to kind of keep this in mind as a
possibility, because maybe wasting CPU time in a big way might actually be
acceptable in some cases, and having a separate flag to enable this kind 
of thing might be interesting, no?

		Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help