Re: On recording renames

From: Linus Torvalds <torvalds@osdl.org>
Date: Mar 4, 2006, 17:36 UTC
Message-ID: <Pine.LNX.4.64.0603040929540.22647@g5.osdl.org>
In-Reply-To: <7v8xrqqrdd.fsf@assigned-by-dhcp.cox.net>

On Sat, 4 Mar 2006, Junio C Hamano wrote:

Show 7 quoted lines

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