public inbox for gentoo-catalyst@lists.gentoo.org
 help / color / mirror / Atom feed
From: William Hubbs <williamh@gentoo.org>
To: gentoo-catalyst@lists.gentoo.org
Subject: Re: [gentoo-catalyst] master rebase of catalyst 2
Date: Sun, 26 Jun 2011 02:56:19 -0500	[thread overview]
Message-ID: <20110626075619.GA7226@linux1> (raw)
In-Reply-To: <4E06D105.6070508@gentoo.org>

[-- 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 --]

  reply	other threads:[~2011-06-26  7:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-26  5:03 [gentoo-catalyst] master rebase of catalyst 2 William Hubbs
2011-06-26  6:26 ` Sebastian Pipping
2011-06-26  7:56   ` William Hubbs [this message]
2011-06-26  8:45     ` William Hubbs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110626075619.GA7226@linux1 \
    --to=williamh@gentoo.org \
    --cc=gentoo-catalyst@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox