Re: Rename handling

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mar 22, 2007, 03:53 UTC
Message-ID: <Pine.LNX.4.64.0703212047310.6730@woody.linux-foundation.org>
In-Reply-To: <200703220432.27071.jnareb@gmail.com>

On Thu, 22 Mar 2007, Jakub Narebski wrote:

> 
> Second, I have thought that rename detection is done on final states: upstream,
> branch and ancestor, not on intermediate commits. I guess I thought wrong.

No, you didn't think wrong, with a few caveats:

 - we *do* do intermediate commits occasionally (ie for the criss-cross 
   merge case and the "recursive" part of the merge strategy). But that's 
   strictly a "we had multiple potential merge bases" issue, not a "track 
   renames through every commit" kind of thing.

 - you should also see the 3-way merge as the *first* strategy. If it 
   fails, you could do more involved stuff (ie the "blame" merge 
   strategy).

Personally, I think the three-way merge (aka "stupid") is absolutely the right thing to do. SCM projects that always try to take intervening commits into account (*cough*darcs*cough*) are just doing masturbation. It's pointless. The history only matters as a "what was the common state" thing, the intermediate mistakes you did in between are meaningless.

But my point is that if you *wanted* to, you could do something fancy. I think it would likely be stupid and wrong, and just cause subtle mismerges rather than actually *help*, but that's just my opinion. Git itself doesn't *force* you to just take the end-points into account, although my opinion that they are the only things that matter certainly may have colored how we do things right now ;)

			Linus