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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 21, 2007, 17:16 UTC
Message-ID: <alpine.LFD.0.98.0706211005520.3593@woody.linux-foundation.org>
In-Reply-To: <7v4pl1zsd7.fsf@assigned-by-dhcp.pobox.com>

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

Show 9 quoted lines

> 
> 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 <greg@kroah.com>
	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 <mochel@segfault.osdl.org>
	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