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