Re: merge smart enough to adapt to renames?

From: Rogan Dawes <lists@dawes.za.net>
Date: Feb 20, 2009, 07:24 UTC
Message-ID: <499E5A9C.6090900@dawes.za.net>
In-Reply-To: <81bfc67a0902191817u11361d0bw1f2215a53e284f8f@mail.gmail.com>

Caleb Cushing wrote:

Show 11 quoted lines

>> Not sure I understood this completely, but I've found it
>> helps to make the rename/move as a separate commit, then
>> start changing stuff.  In other words, do too many things in
>> the same commit, and you could lose this coolness.
> 
> well I the problem is.. in a sense I need to unmerge 2 files that I
> once merged... they currently have the same name and are in the same
> place, and where I merge them from they'll continue to have that  name
> (although they are different files with the same purpose) but I want
> them to have different names and spots in my tree/repo.
>

Not having done this myself, I'd take this following suggestion with a grain of salt! :-)

It seems to me that git is smart enough to figure out where contents get moved to, once. Of course, if you have conflicting moves in the same repo, git's automation falls down. So, if you need to move the "same" file in different repositories to different places, you need to do it via an intermediate repo that will be able to "remember" which movement you chose.

e.g. upstream A: data <- contains one set of data

upstream B: data <- contains another set of data

pull upstream A into intermediate A, move the file as desired, and commit: Intermediate A: data/upstreamA

pull upstream B into intermediate B, move the file as desired, and commit: Intermediate B: data/upstreamB

merge Intermediate A and Intermediate B in master: master: data/upstreamA data/upstreamB

Then, subsequent pulling from upstream A into Intermediate A will "remember" the move of "data" to "data/upstreamA", and similarly with B. Subsequent merges of Intermediates A & B into master will end in the desied result.

Hope this helps.

Rogan