merge smart enough to adapt to renames?

merge smart enough to adapt to renames?

[Caleb Cushing]

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?

-- 
Caleb Cushing

http://xenoterracide.blogspot.com

Re: merge smart enough to adapt to renames?

[Sitaram Chamarty]

On 2009-02-19, Caleb Cushing <xenoterracide@gmail.com> wrote:
> 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...

Re: merge smart enough to adapt to renames?

[Caleb Cushing]

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

http://xenoterracide.blogspot.com

Re: merge smart enough to adapt to renames?

[Sitaram Chamarty]

On 2009-02-19, Caleb Cushing <xenoterracide@gmail.com> wrote:
>> 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.

There's some logic somewhere that says "if we can't find a
match to merge this file, let's see if we ever had the same
blob as the parent of the file in the MERGE_HEAD and we'll
use that as a base to do the merge".

Re: merge smart enough to adapt to renames?

[Caleb Cushing]

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

-- 
Caleb Cushing

http://xenoterracide.blogspot.com

Re: merge smart enough to adapt to renames?

[Rogan Dawes]

Caleb Cushing wrote:
>> 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

Re: merge smart enough to adapt to renames?

[Kris Shannon]

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)

Re: merge smart enough to adapt to renames?

[Rogan Dawes]

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

Yes, of course.

Rogan

Re: merge smart enough to adapt to renames?

[Caleb Cushing]

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

-- 
Caleb Cushing

http://xenoterracide.blogspot.com

Re: merge smart enough to adapt to renames?

[Rogan Dawes]

Caleb Cushing wrote:
> 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