On Sat, 4 Mar 2006, Junio C Hamano wrote: > > An ideal merge strategy would handle the case where pieces of > code gradually moves around across file boundaries. I do not > think this is something you can sensibly do by recording file > rename history. It would not help the situation a bit even if > you gave each file (or content or object or whatever you want to > call it) a persistent ID. Actually, we have an absolutely perfect example of this much closer to home. I originally did the "rev-list split" series on an older version of git, before you did the --objects-edge and the full pathname hashing improvements. But when I was done, you'd merged that, and I needed to merge my rev-list.c split with your improvements in order to send it to you. Now, the whold file hadn't actually been renamed, but about 50% of that file had been split into a new one. So effectively you had a merge where part of the new stuff had to be merged into another file. Now, I think this is actually more common than renames in many ways. It's not a "complete" rename, but as far as _part_ of your changes were concerned, it was one. And yes, such a split can be something that is done in stages, again exactly the same way about 85% of rev-list.c was moved into revision.c in two stages: the first stage was the argument parsing and setup, and the second stage was the actual revision walking logic. Linus - : 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