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

On Thu, 21 Jun 2007, Linus Torvalds wrote:

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".

Btw, just to clarify:

	This is absolutely not somethign unique to "--follow" and rename 
	detection!

when you do a simple "git log -p", you will very commonly see the issue of 
the same patch being applied twice, and if you think of the linearized 
"git log" output is somehow "the Truth" with a capital "T", then you'd 
obviously believe that the thing shows up twice in the end result.

It doesn't even have to be the same patch: you can have a patch that shows 
up in one branch, and that *never* makes it into the end result, even 
though the other branch didn't "undo" it. A merge may have chosen just the 
one side (not necessarily due to "-s ours" or anythign like that: a merge 
conflict may have been resoled that way). 

So the individual logs of changes are not "meaningful" in that sense. Not 
with --follow, and not without. They are a locally linearized version of 
history, and as such you cannot put the world together just based on them. 
You need to have the bigger picture to get the end result.

Does that mean that linearization is meaningless? No, obviously not. Does 
it mean that you *can* get confused by it? Yes, absolutely. Does rename 
detection add new _ways_ of getting confused? Oh, YES! The example from 
the kernel is a great one.

I still think "git log --follow" is actually a really good thing. People 
will find places like this where they are confused, and maybe we'll have 
to teach them about the effects of linearizing their history, but 
especially if you come from the CVS/SVN world, your history has _always_ 
been linear, so git will always get that case right. 

And once you get used to merges, you'll start understanding why git does 
what git does more, and then the "git log --follow" behaviour will still 
perhaps not be what you might always want at any particular point in time, 
but it's something you can understand and deal with.

And it's still hugely preferable to "file identities", which have their 
own (and much more fundamental) problems over merges.

		Linus