Re: What's cooking in git.git (topics)

On Thu, 21 Jun 2007, Junio C Hamano wrote:

Also I am not convinced its handling of merges is sane.  If you
have an ancestry graph like this, and the commit A renames the
followed path, it would show the file _before_ rename, which is
very good.

      o-------B---A---o----o
                     /  
        o----C------'

I agree. That's even what I tried to explain (but your graph is better) in 
my commit message, when I was talking about how it linearizes the history 
in "git log" order, and decides that renames happen "within that 
linearized" world.

You can actually see an *example* of this by doing

	git log --stat --follow arch/i386/pci/common.c

on the old historical Linux archive (the BK import one, not the bkcvs 
import - the latter has been linearized by bkcvs so won't show concurrent 
development anyway). 

What you get is:

	[ ... ]

	commit f9001d4262148fbfb7ecdcb88c73d9791c1ac0ad
	Author: Greg Kroah-Hartman [off-list ref]
	Date:   Mon May 6 20:18:16 2002 -0700
	
	    Move arch/i386/kernel/pci/ to arch/i386/pci/
	
	 arch/i386/{kernel => }/pci/common.c |    0
	 1 files changed, 0 insertions(+), 0 deletions(-)
	
	commit bbb283cca10b2d2c935ae35327620ebae07f7d80
	Author: Patrick Mochel [off-list ref]
	Date:   Mon May 6 20:09:44 2002 -0700
	
	    Move arch/i386/kernel/pci/ to arch/i386/pci/
	
	 arch/i386/kernel/pci/common.c |  206 -----------------------------------------
	 1 files changed, 0 insertions(+), 206 deletions(-)

	[ ... ]

and this is an artifact of two _concurrent_ directory moves, and look at 
what "git log --follow" did: it actually found the rename (we looked at 
Greg's version first), but then *because* it found the rename, it is now 
starting to look at the *previous* name, which was

	arch/i386/kernel/pci/common.c

and when it then sees the rename in Pat's commit, it's no longer finding 
that previous entry as a "new file that got created" (which triggers the 
rename logic), but now it finds that filename has being *removed* (because 
the _old_ filename really did go away - it got renamed!)

This is 100% logical within that linearized history, but it's a bit 
surprising. But it's how "git log --follow" just works.

If you want to see the real history, you need to do it with "git blame", 
which actually understands about merges, or with some graphical viewer 
that would be extended to follow renames when it notices that a filename 
goes away.

But "git log" itself really fundamentally has no clue, and you really 
should see "git log" as a *linearization* thing. It linearizes the history 
by creating a one-dimensional streaming log. And within that linearized 
history, there can not be anything like "concurrent renames".

			Linus