merge smart enough to adapt to renames?

> branch gentoo.org has a file profiles/package.mask
>
> the software that uses this supports having this be a directory as well.
>
> I'm thinking of mv-ing this file in branch regen2.org to
> profiles/package.mask/gentoo.org
>
> since I can't change the location in gentoo.org (for mostly
> non-technical reasons) when I run git merge gentoo.org from regen2.org
> will git be smart enough to try to merge an updated
> profiles/package.mask into profiles/package.mask/gentoo.org in the
> future?

>> Yes.  I maintain two copies of something (in different
>> repos) like this...
>
> nice... now the real kicker if I merge from another branch
> sunrise/reviewed and redirect it's package.mask to
> package.mask/sunrise will git be smart enough to differentiate from
> the gentoo.org one and the sunrise one? I think even more important is
> how would I even tell it to do that once I've moved the first one.

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

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

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

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

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