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

[William Hubbs]

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