Re: Rename handling

[Linus Torvalds <torvalds@linux-foundation.org>]

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