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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 21, 2007, 17:44 UTC
Message-ID: <alpine.LFD.0.98.0706211034500.3593@woody.linux-foundation.org>
In-Reply-To: <alpine.LFD.0.98.0706211005520.3593@woody.linux-foundation.org>

On Thu, 21 Jun 2007, Linus Torvalds wrote:

Show 5 quoted lines

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