[gentoo-catalyst] master rebase of catalyst 2

[gentoo-catalyst] master rebase of catalyst 2

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

All,

I checked out a local branch from master earlier today and rebased that
on catalyst_2. Now that branch has over 100 commits, which will be the
combination of everything on catilyst 2 and current master.

So, how would you suggest we get that branch back out where everyone can
see it? Do you want me to put it back out on master? It won't be a
forced update, because I used rebase instead of merge.

The only catch is I don't know how broken that will leave master.

What are your thoughts?

William

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-catalyst] master rebase of catalyst 2

[Sebastian Pipping]

On 06/26/2011 07:03 AM, William Hubbs wrote:
> All,
> 
> I checked out a local branch from master earlier today and rebased that
> on catalyst_2. Now that branch has over 100 commits, which will be the
> combination of everything on catilyst 2 and current master.
> 
> So, how would you suggest we get that branch back out where everyone can
> see it? Do you want me to put it back out on master? It won't be a
> forced update, because I used rebase instead of merge.
> 
> The only catch is I don't know how broken that will leave master.

That sentence^^^ rings at least warning bells in my ears.  I don't know
how well you know the code, how easy conflicts were to solve.  What may
be important is that we have little (if any) test cases and that we get
little help from Python and Bash to detect breakage for us.  If that
transition adds a pile of bugs that we'll find by chance somewhere next
year, that would be a problem.

Personally I may have chosen a road moving both branches towards each
other until their diff resolves to zero and than add a fake merge
commit.  But that's dry theory - no idea if that would have worked well.
Plus I woulnd't make it alone and not in a few days or hours.


> What are your thoughts?

Please put them on a new branch (not master) while we're not sure ff the
resulting commits could or should be the future.

Thanks,




Sebastian

Re: [gentoo-catalyst] master rebase of catalyst 2

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 2672 bytes --]

On Sun, Jun 26, 2011 at 08:26:13AM +0200, Sebastian Pipping wrote:
> On 06/26/2011 07:03 AM, William Hubbs wrote:
> > All,
> > 
> > I checked out a local branch from master earlier today and rebased that
> > on catalyst_2. Now that branch has over 100 commits, which will be the
> > combination of everything on catilyst 2 and current master.
> > 
> > So, how would you suggest we get that branch back out where everyone can
> > see it? Do you want me to put it back out on master? It won't be a
> > forced update, because I used rebase instead of merge.
> > 
> > The only catch is I don't know how broken that will leave master.
> 
> That sentence^^^ rings at least warning bells in my ears.  I don't know
> how well you know the code, how easy conflicts were to solve.  What may
> be important is that we have little (if any) test cases and that we get
> little help from Python and Bash to detect breakage for us.  If that
> transition adds a pile of bugs that we'll find by chance somewhere next
> year, that would be a problem.

The thing is, I think catalyst 3 is broken anyway; we need to  hear from
agaffney for sure what the status is.

 I know that the catalyst_2 branch is what releng is using to do their
 official builds.

> Personally I may have chosen a road moving both branches towards each
> other until their diff resolves to zero and than add a fake merge
> commit.  But that's dry theory - no idea if that would have worked well.
> Plus I woulnd't make it alone and not in a few days or hours.
 
 I've never been able to figure out how to read merge commits when I use
 git log, so I try to stay away from them. My usual approach is to make
 master be where things come down from upstream, then I work on local
 branches. When I am ready to add something to master, I usually do
 this:

 git checkout master
 git pull # make sure master is up to date
git rebase master mybranch # rebases "mybranch" changes on current master
 git checkout master
 git merge mybranch # this makes a fast-forward merge at this point
git pull --rebase #update master with my changes at the end
git push #add my changes to master

> Please put them on a new branch (not master) while we're not sure ff the
> resulting commits could or should be the future.

Hmm, that will mean that all commits we are working on have to go to
catalyst_2, the new branch, and master; I think that will make things
even more complicated than they already are.

I think want to try to find a way to bring the commits on catalyst_2
that are not on master over to master, so I may give it another shot
before I do anything.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-catalyst] master rebase of catalyst 2

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

All, it is safe to forget about the branch I was talking about with over
100 commits on it. Git has some tools which can help us figure out which
commits need to go to master from catalyst_2.

First, make sure your repository is up to date.

Once that is done, one thing you can do is look at the commits on
catalyst_2 by exporting them to patches.

To do this, check out the catalyst_2 branch and run this command:

git format-patch master

That will turn all of the commits on catalyst_2 into patches and save
them in your current directory.

It is also possible to let git tell you which commits it thinks are
already on master by running this command while you are on the catalyst_2 branch.

git cherry master

This produces a list of commit hashes preceeded by '+' or '-'. In this
example, the commits that start with '+' are the ones git thinks are
NOT in the master branch.

At that point it will be a matter of looking at each commit manually,
deciding if it needs to be ported to master and making the appropriate
change on master as well.

Do you have any thoughts about how we can go about forward porting these
changes from catalyst_2 to master?

Thanks,

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]