Re: merge smart enough to adapt to renames?

From: Rogan Dawes <lists@dawes.za.net>
Date: Feb 22, 2009, 17:13 UTC
Message-ID: <49A187CD.2020403@dawes.za.net>
In-Reply-To: <81bfc67a0902211700m7a0d0ae8jd17a871ba102fd9f@mail.gmail.com>

Caleb Cushing wrote:

Show 30 quoted lines

> On Fri, Feb 20, 2009 at 11:48 PM, Kris Shannon <kris@shannon.id.au> wrote:
>> Rogan Dawes wrote:
>>> 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.
>> You don't need a whole different repo,  branches are good enough.
>>
>> git checkout gentoo-integration
>> git pull gentoo
>>
>> git checkout sunrise-integration
>> git pull sunrise
>>
>> git checkout master
>> git merge gentoo
>> git merge sunrise
>>
>> The integration branches can remember your local changes to
>> the remotes (like the move of packages.mask)
>>
> 
> it sounds like a decent plan on paper... but when you realize each
> checkout is 100,000+ files...to where as if I create a repo just for
> it... it ends up being like 5 files... and I'm not entirely sure that
> has much of a negative side effect... other than... yet another
> remote...
>

Well, if you use an "integration branch", rather than a whole separate repository, that should simplify things, I think.

And, if the differences between the branches are limited to those 5 files, a checkout (if you even really need to check it out) will only update those files that are different between the branches. It may even be possible to do an "in index" merge, without even having a checkout, if there are no conflicts.

Rogan