master rebase of catalyst 2
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
> 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
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.