FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Catalyst

 
 
LinkBack Thread Tools
 
Old 06-27-2011, 04:44 AM
William Hubbs
 
Default rfc: merging catalyst git branches

All,

this has been mentioned in a couple of threads, so I want to bring it up
in a separate thread so that we can keep the discussions organized. :-)

As you know, catalyst has two branches in its git repository, master,
which was going to be catalyst 3.0, and a branch called catalyst_2 which
is the branch being used by releng for official releases.

We know from what Jorge said that the master branch is broken.

Right now, we are commiting changes to both branches, but that is not a
good idea over the long term. We need to figure out if we should keep
master and try to release 3.0 from there at some point. If that is what
we want to do, we need to go through the catalyst_2 branch and port
relevant commits to master.

If we are not interested in the 3.0 code, we should probably find a way
to revert all of it from master with one commit then rebase the 2.0
branch on master and move it back there.

What are your thoughts, especially releng, because you did a lot of work
on the 3.0 code. If we port commits from catalyst_2 to the 3.0 branch,
can we get that code up and running? What commits on that branch should
be ported?

William
 
Old 12-08-2011, 06:46 PM
William Hubbs
 
Default rfc: merging catalyst git branches

On Sun, Jun 26, 2011 at 11:44:33PM -0500, William Hubbs wrote:
> All,
>
> this has been mentioned in a couple of threads, so I want to bring it up
> in a separate thread so that we can keep the discussions organized. :-)
>
> As you know, catalyst has two branches in its git repository, master,
> which was going to be catalyst 3.0, and a branch called catalyst_2 which
> is the branch being used by releng for official releases.
>
> We know from what Jorge said that the master branch is broken.
>
> Right now, we are commiting changes to both branches, but that is not a
> good idea over the long term. We need to figure out if we should keep
> master and try to release 3.0 from there at some point. If that is what
> we want to do, we need to go through the catalyst_2 branch and port
> relevant commits to master.
>
> If we are not interested in the 3.0 code, we should probably find a way
> to revert all of it from master with one commit then rebase the 2.0
> branch on master and move it back there.

If no one objects, I will look into doing this next week; the catalyst_2
code should move to master since there doesn't appear to be any work
going on for releasing catalyst 3.

Comments?

William
 
Old 12-08-2011, 07:31 PM
Sebastian Pipping
 
Default rfc: merging catalyst git branches

On 12/08/2011 08:46 PM, William Hubbs wrote:
>> [..]
>>
>> If we are not interested in the 3.0 code, we should probably find a way
>> to revert all of it from master with one commit then rebase the 2.0
>> branch on master and move it back there.
>
> If no one objects, I will look into doing this next week; the catalyst_2
> code should move to master since there doesn't appear to be any work
> going on for releasing catalyst 3.
>
> Comments?

Sounds like you are going for complete replacement. Good move.


The cleanest way to do this this in Git may be:

# git checkout master
# git merge -s theirs catalyst_2

Haven't tested it though.

Best,



Sebastian
 
Old 12-08-2011, 08:42 PM
William Hubbs
 
Default rfc: merging catalyst git branches

On Thu, Dec 08, 2011 at 09:31:26PM +0100, Sebastian Pipping wrote:
> On 12/08/2011 08:46 PM, William Hubbs wrote:
> > If no one objects, I will look into doing this next week; the catalyst_2
> > code should move to master since there doesn't appear to be any work
> > going on for releasing catalyst 3.
> >
> > Comments?
>
> Sounds like you are going for complete replacement. Good move.
>
>
> The cleanest way to do this this in Git may be:
>
> # git checkout master
> # git merge -s theirs catalyst_2
>
> Haven't tested it though.

I checked it out with the folks on #git, and they are recommending
that I rename catalyst_2 to master. I was given a series of commands to
do this.

The down side is that this will cause a forced update, so everyone will
have to re-clone the repository.

The target time I am considering for this is Monday, Dec 11, 0:00 utc.
What that means is, everyone needs to have their changes pushed by then,
then I'll make the change and send out an email here once I'm done.
Then, you will have to re-clone your repositories.

Any comments?

Thanks,

William
 
Old 12-08-2011, 10:43 PM
Sebastian Pipping
 
Default rfc: merging catalyst git branches

On 12/08/2011 10:42 PM, William Hubbs wrote:
>> The cleanest way to do this this in Git may be:
>>
>> # git checkout master
>> # git merge -s theirs catalyst_2
>>
>> Haven't tested it though.

Just noticed that I mis-read the git-merge man page: "theirs" is an
option of the recursive merge strategy. Sorry.


> I checked it out with the folks on #git, and they are recommending
> that I rename catalyst_2 to master. I was given a series of commands to
> do this.
>
> The down side is that this will cause a forced update, so everyone will
> have to re-clone the repository.

Actually there is a way to do this *without* the downside that you describe.

The trick is to create a fake merge commit using git commit-tree to sort
of emulate merge strategy "theirs". The commit to make needs to:

- point to catalyst_2^{tree} as its content.

- have current catalyst_2 as its *first* parent in order to
- indicate where the data actually came from
- make commands like "git show HEAD^" descend into
the old catalyst_2 branch later as that's the content
that matters

- have current master as the second parent
(so people can keep working without trouble)


This time I tested it myself. This is what to do:

1) Make sure your local master and catalyst are *both* up to date.

2) # git checkout master

3) Create and merge a fake merge commit as defined above:

# git merge $(git commit-tree catalyst_2^{tree}
-p catalyst_2 -p master
<<<"Replace content on master with content from catalyst_2")

Again, the *order* of parents matters.

4) Confirm it went fine, e.g. this diff should now be empty:

# git diff master catalyst_2


> The target time I am considering for this is Monday, Dec 11, 0:00 utc.
> What that means is, everyone needs to have their changes pushed by then,
> then I'll make the change and send out an email here once I'm done.
> Then, you will have to re-clone your repositories.
>
> Any comments?

Please consider the alternative explained above.

What do you think?


Best,



Sebastian
 
Old 12-09-2011, 12:55 AM
"Jorge Manuel B. S. Vicetto"
 
Default rfc: merging catalyst git branches

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08-12-2011 18:46, William Hubbs wrote:
> On Sun, Jun 26, 2011 at 11:44:33PM -0500, William Hubbs wrote:
>> All,
>>
>> this has been mentioned in a couple of threads, so I want to
>> bring it up in a separate thread so that we can keep the
>> discussions organized. :-)
>>
>> As you know, catalyst has two branches in its git repository,
>> master, which was going to be catalyst 3.0, and a branch called
>> catalyst_2 which is the branch being used by releng for official
>> releases.
>>
>> We know from what Jorge said that the master branch is broken.
>>
>> Right now, we are commiting changes to both branches, but that is
>> not a good idea over the long term. We need to figure out if we
>> should keep master and try to release 3.0 from there at some
>> point. If that is what we want to do, we need to go through the
>> catalyst_2 branch and port relevant commits to master.
>>
>> If we are not interested in the 3.0 code, we should probably find
>> a way to revert all of it from master with one commit then rebase
>> the 2.0 branch on master and move it back there.
>
> If no one objects, I will look into doing this next week; the
> catalyst_2 code should move to master since there doesn't appear to
> be any work going on for releasing catalyst 3.
>
> Comments?

William,

I'd rather not lose the work for catalyst_3. I understand and agree we
use the catalyst_2 branch for our releases, so I'd rather move master
to a new branch, call it catalyst_3, experimental or something else,
and then make catalyst_2 as master.


> William
>

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJO4WqaAAoJEC8ZTXQF1qEPfQwQALbl7ut059 PYHqMZFFmKyjy7
Y7PMRB1UroTVOA3atyo2abGZ9PmL34Gh2ns1SF2LxXSP2TlUuS TzswTlEvPj9Stc
zsmcfxH+OpKAykgV1UJjc6PTuarlGRihmOES2ezLSneoKxvvSX bIH37wqGFOCld/
bzaFjBL/TCvfXZIeXngHQ9SXIdEp9IWKlL14/WGmiP2iKeHPZ8O4j0k/OL8h1Nvx
BTD83F1UruELkWkLQz7F/yGW64AFH5EzIC4ebnA9NMv6KhsF5G2VDfwEKuJwgCAe
XE8Jt9IdEDX9akOflHlCLo7iwPyMsssGqXUo53b/uThOusRZkSvNG0+jVOvTL4oh
387VFXo3cNKPyQns/EQQml2jF2MNCqbHVEeW/s3IzQg6NGT3JNu5wjHTJz1hcaqs
rcb54+F/jwhd1J4s+xXKuU0sJAJvmFGneHfCnPs+EMXLS2mGw1YNu4+FlK wLwdQN
FTYhUB/kyFHM/c2MGTO2V/M3dt5efu5tgaF1QqCfsOQiR2dXIGkHqStLqZHHfK2J
Ets+epXt3iGIN0udKIEWSqaAwKQW40RstbWlEcUT2TD0GBjW+l n5oU/d4KkvS2rn
IBfN+19hW2OFt0KYo+Bc2GTYCRIPaRYDikyib4ZnzKhSnGKMjx PGYiczmgDIcvr8
FQwNtsOccSDK69tD49FQ
=96Ty
-----END PGP SIGNATURE-----
 
Old 12-09-2011, 01:56 AM
Sebastian Pipping
 
Default rfc: merging catalyst git branches

On 12/09/2011 02:55 AM, Jorge Manuel B. S. Vicetto wrote:
> I'd rather not lose the work for catalyst_3. I understand and agree we
> use the catalyst_2 branch for our releases, so I'd rather move master
> to a new branch, call it catalyst_3, experimental or something else,
> and then make catalyst_2 as master.

The code remains in Git, we don't really lose it.
To easy up accessing it in the future, all you need to do now is

A) add a tag or

B) start a branch

where the master branch is now, as you prefer.

Best,



Sebastian
 
Old 12-09-2011, 02:19 AM
William Hubbs
 
Default rfc: merging catalyst git branches

On Fri, Dec 09, 2011 at 12:55:38AM -0100, Jorge Manuel B. S. Vicetto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 08-12-2011 18:46, William Hubbs wrote:
> > On Sun, Jun 26, 2011 at 11:44:33PM -0500, William Hubbs wrote:
> >> All,
> >>
> >> this has been mentioned in a couple of threads, so I want to
> >> bring it up in a separate thread so that we can keep the
> >> discussions organized. :-)
> >>
> >> As you know, catalyst has two branches in its git repository,
> >> master, which was going to be catalyst 3.0, and a branch called
> >> catalyst_2 which is the branch being used by releng for official
> >> releases.
> >>
> >> We know from what Jorge said that the master branch is broken.
> >>
> >> Right now, we are commiting changes to both branches, but that is
> >> not a good idea over the long term. We need to figure out if we
> >> should keep master and try to release 3.0 from there at some
> >> point. If that is what we want to do, we need to go through the
> >> catalyst_2 branch and port relevant commits to master.
> >>
> >> If we are not interested in the 3.0 code, we should probably find
> >> a way to revert all of it from master with one commit then rebase
> >> the 2.0 branch on master and move it back there.
> >
> > If no one objects, I will look into doing this next week; the
> > catalyst_2 code should move to master since there doesn't appear to
> > be any work going on for releasing catalyst 3.
> >
> > Comments?
>
> William,
>
> I'd rather not lose the work for catalyst_3. I understand and agree we
> use the catalyst_2 branch for our releases, so I'd rather move master
> to a new branch, call it catalyst_3, experimental or something else,
> and then make catalyst_2 as master.

Hi Jorge,

Ok, no problem, I'll go back to the #git channel tomorrow and
investigate how to do that.

I would prefer to do it without merge commits if possible, but that may
mean a forced update. Are you ok with that?

William
 
Old 12-09-2011, 03:42 AM
Sebastian Pipping
 
Default rfc: merging catalyst git branches

On 12/09/2011 04:19 AM, William Hubbs wrote:
> Hi Jorge,
>
> Ok, no problem, I'll go back to the #git channel tomorrow and
> investigate how to do that.

Have you received my other mail with notes on git commit-tree and how it
can help here? It was sent "Fri, 09 Dec 2011 00:43:45 +0100".


> I would prefer to do it without merge commits if possible

What would be the gain here?


>, but that may
> mean a forced update. Are you ok with that?

I would rather not see that. Is there is a problem with the git
commit-tree approach that you see but I don't? Please let me hear about it.

Best,




Sebastian
 
Old 12-09-2011, 03:16 PM
William Hubbs
 
Default rfc: merging catalyst git branches

On Fri, Dec 09, 2011 at 05:42:03AM +0100, Sebastian Pipping wrote:
> On 12/09/2011 04:19 AM, William Hubbs wrote:
> > Hi Jorge,
> >
> > Ok, no problem, I'll go back to the #git channel tomorrow and
> > investigate how to do that.
>
> Have you received my other mail with notes on git commit-tree and how it
> can help here? It was sent "Fri, 09 Dec 2011 00:43:45 +0100".

Yes, I saw it, but it doesn't seem to do what we want. It merges the
branches together instead of swapping them.

> > I would prefer to do it without merge commits if possible

What I want is something like:

git branch -m master catalyst_3
git branch -m catalyst_2 master
# now update the upstream repo to match this.
# I'm not sure if this will cause a forced update or not though.

>
> What would be the gain here?

The gain is that git log doesn't show a merge commit, and you aren't
pushing another 70 plus commits to the master branch, so you keep the
history clean.

Best,

William
 

Thread Tools




All times are GMT. The time now is 01:43 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org