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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html