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 <greg@xxxxxxxxx>
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@xxxxxxxxxxxxxxxxx>
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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
