Re: [PATCH RFC] rebase: add --revisions flag

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Dec 09, 2009 at 02:19:45PM +0100, Björn Steinbrink wrote:
> On 2009.12.08 22:00:17 +0200, Michael S. Tsirkin wrote:
> > On Tue, Dec 08, 2009 at 08:11:07PM +0100, Björn Steinbrink wrote:
> > > So you can already do what you want to do, but wrapping it in a single
> > > porcelain might still be useful because it's obviously a  lot easier and
> > > safer that way. That said, I wonder what kind of workflow you're using
> > > though, and why you require that feature. I've never needed something
> > > like that.
> > 
> > I need this often for many reasons:
> > -	Imagine developing a patchset with a complex bugfix on master branch.
> > 	Then I decide to also apply (backport) this patchset to stable branch.
> 
> Hm, I'd also imagine that you want a separate branch then, and not
> directly mess up the stable branch,

Well, directly working with a stable branch is easier, so yes,
I want to mess it up: this is just my local tree, if anything
goes wrong  I just don't push or "reset --hard origin/stable".

> so I'd do:
> git branch foo-stable foo # Create a branch for the backport
> git rebase --onto stable master foo-stable # Backport
> 
> Now you got your backported version and can merge it to "stable".

The annoying thing is that merge step. I can create a merge
commit if I mistype things, and I do not want any
merge commits, I want to create linear history.

> Common wisdom is do things the other way around though. Create the
> bugfix for the oldest branch that it applies to, then merge it forward,
> either doing:
> 
> "bugfix -> stable" and "stable -> master" merges, or
> "bugfix -> stable" and "bugfix -> master" merges.
> 
> That approach has the advantage that you don't get multiple commits
> doing the same thing, which you get with rebasing/cherry-picking.
> 
> IIRC the gitworkflows manpage describe that in some more detail.


I know. The advantage of making all changes to master first
is that this way a change gets more review and testing before
being applied to stable. Further, often different people
maintain master and stable branches.

> > -	Imagine developing a bugfix/feature patchset on master branch.
> > 	Then I decide the patchset is too large/unsafe and want to
> > 	switch it to staging branch.
> 
> Hm, so you have a topic branch "foo" based upon master, but it's too
> experimental so you don't want to merge it to master, but "staging". I
> don't see why you even have to rebase it then. "staging" is likely ahead
> of master, so the merge base of "foo" and "master" is also reachable
> through "staging", and simply merging "foo" to "staging" should work
> without any ill-effects.

Yes but I want my development history to be linear,
so that format patch rebase -i etc work well.

> > -	I have a large queue of patches on staging branch, I decide that
> > 	a range of patches is mature enough for master.
> 
> Basically, same deal as with the first two cases. If the series is
> directly on "staging" (i.e. you didn't create a topic branch), you can
> create one now:
> git branch foo $last_commit_for_foo
> git rebase --onto master $first_commit_for_foo^ foo
> 
> And you got your backported topic branch for "foo".
> 
> Or you already have a topic branch "foo-staging", but it's based upon
> some commit only in "staging" but not in "master", so a plain merge
> would mess things up. Same deal as with backporting from "master" to
> "stable"

Yes, I understand that creating a temporary branch and checking it out
then merging it will make rebase do what I want.
The only disadvantage is that I need to remember where I am in the
process, while an "atomic" command does this for me.

> And in this case it's also true that basing the topic branches on
> "master" instead of "staging" makes things easier. That way, you can
> merge to either "staging" or "master" without any ill-effects.
> 
> Björn

As above, I do not want merges.