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, 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". 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. > - 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. > - 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" 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 -- 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