{"thread":{"id":"44798","subject":"Rebasing multiple branches at once","startedAt":"2016-12-31T21:42:56Z","lastAt":"2017-01-02T06:42:23Z","messageCount":4,"participants":["Mike Hommey","Junio C Hamano","Johannes Sixt","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"308555","messageId":"20161231081433.3zo6lrsjsu2qho4u@glandium.org","threadId":"44798","inReplyTo":null,"subject":"Rebasing multiple branches at once","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2016-12-31T08:14:33Z","receivedAt":"2016-12-31T21:42:56Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"Hi,\n\nI've had this kind of things to do more than once, and had to do it a\nlot today, so I figured it would be worth discussing whether git-rebase\nshould be enhanced to support this, or if this should go in a separate\ntool or whatever.\n\nSo here is what I'm trying to do in a not-too painful way:\n\nI'm starting with something like this:\nA---B---C---D---E\n \\---F\n\nwhere A is master, and E and F are two local topics with a common set of\nthings on top of master.\n\nThe next thing that happens is that master is updated, and I want to\nrebase both topics on top of the new master.\n\nSo I now have:\n\nA---G\n\\---B---C---D---E\n \\---F\n\nIf I do the dumb thing, which is to do `git rebase master E` and `git\nrebase master F`, I end up with:\n\nA---G---B'---C'---D'---E'\n \\---B\"---C\"---D\"---F'\n\nThat is, I just lost the fast that E and F had common history.\n\nI could go with `git rebase master E` followed by `git rebase --onto D'\nD F` but that's cumbersome, especially when you have more than 2 topics,\nnot necessarily diverging at the same point (e.g. I might have another\ntopic that diverges at C)\n\nSo, what I end up doing is something like:\n- git co -b merge E\n- git merge --strategy ours F (and any other topic I might want to\n rebase)\n- git rebase master --preserve-merges\n\nIf everything goes fine, then I can `git update-ref` the topics to each\nparent of the merge branch.\n\nBut, usually, since rebase --preserve-merges redoes merges with the\ndefault strategy, I end up with conflicts, and instead of trying to\nfigure stuff out, I just pick the rewritten sha1s from\n.git/rebase-merge/rewritten/* to update the refs.\n\nIt is my understanding that the --strategy option to git-rebase is used\nfor the rebase itself, so I'm not sure there's a way to tell rebase to\nuse a specific strategy for the preserved merges only.\n\nAnyways, it /seems/ like just allowing multiple branches on the git\nrebase command line and make this work would improve things\nsignificantly. The question then, is how would that interact with other\noptions (I'm thinking e.g. -i, but -i already has a problem with\n--preserve-merges). But it does seem like it would be a worthwhile\nimprovement.\n\nWhat do you think?\n\nMike\n"},{"id":"308565","messageId":"xmqqmvfb4i5a.fsf@gitster.mtv.corp.google.com","threadId":"44798","inReplyTo":"20161231081433.3zo6lrsjsu2qho4u@glandium.org","subject":"Re: Rebasing multiple branches at once","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-01-01T02:40:33Z","receivedAt":"2017-01-01T02:40:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey writes:\n\n> So I now have:\n>\n> A---G\n> \\---B---C---D---E\n> \\---F\n>\n> If I do the dumb thing, which is to do `git rebase master E` and `git\n> rebase master F`, I end up with:\n>\n> A---G---B'---C'---D'---E'\n> \\---B\"---C\"---D\"---F'\n>\n\nWhat people seem to do is to teach the branch that ends with F that\nits upstream is the local branch that ends with E, so that they can\nbe lazy when rebasing a branch that knows its upstream. I suspect\nthat you would end up with\n\nA---G---B'--C'--D'--E'--F'\n\ninstead if it is done naively, but if you really care that the\nbranch that ends with F does not have E, you presumably want to have\nthe branch that ends at D its own identity, so\n\n (1) 'master' or whatever that used to end at A and now its tip is\n at G;\n\n (2) the branch that ends at D whose upstream is 'master';\n\n (3) the branch that ends at E whose upstream is (2); and\n\n (4) the branch that ends at F whose upstream is (2).\n\nI personally do not do that, though, because you'd need to remember\nthe order in which these three branches must be rebased (i.e. (2)\nmust be done first before rebasing (3) and (4) in any order).\n\n"},{"id":"308570","messageId":"3f29bd56-6f63-c035-71d3-9b2f2577b998@kdbg.org","threadId":"44798","inReplyTo":"20161231081433.3zo6lrsjsu2qho4u@glandium.org","subject":"Re: Rebasing multiple branches at once","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2017-01-01T08:42:51Z","receivedAt":"2017-01-01T08:43:00Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 31.12.2016 um 09:14 schrieb Mike Hommey:\n> Hi,\n>\n> I've had this kind of things to do more than once, and had to do it a\n> lot today, so I figured it would be worth discussing whether git-rebase\n> should be enhanced to support this, or if this should go in a separate\n> tool or whatever.\n>\n> So here is what I'm trying to do in a not-too painful way:\n>\n> I'm starting with something like this:\n> A---B---C---D---E\n> \\---F\n>\n> where A is master, and E and F are two local topics with a common set of\n> things on top of master.\n>\n> The next thing that happens is that master is updated, and I want to\n> rebase both topics on top of the new master.\n>\n> So I now have:\n>\n> A---G\n> \\---B---C---D---E\n> \\---F\n>\n> If I do the dumb thing, which is to do `git rebase master E` and `git\n> rebase master F`, I end up with:\n>\n> A---G---B'---C'---D'---E'\n> \\---B\"---C\"---D\"---F'\n>\n> That is, I just lost the fast that E and F had common history.\n\nGit garden shears, perhaps?\n\nhttps://public-inbox.org/git/alpine.DEB.2.20.1609111027330.129229@virtualbox/\n\n-- Hannes\n\n"},{"id":"308604","messageId":"20170102064214.5fvjyv54c7wbrk2i@sigill.intra.peff.net","threadId":"44798","inReplyTo":"xmqqmvfb4i5a.fsf@gitster.mtv.corp.google.com","subject":"Re: Rebasing multiple branches at once","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-01-02T06:42:14Z","receivedAt":"2017-01-02T06:42:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 31, 2016 at 06:40:33PM -0800, Junio C Hamano wrote:\n\n> What people seem to do is to teach the branch that ends with F that\n> its upstream is the local branch that ends with E, so that they can\n> be lazy when rebasing a branch that knows its upstream. I suspect\n> that you would end up with\n> \n> A---G---B'--C'--D'--E'--F'\n> \n> instead if it is done naively, but if you really care that the\n> branch that ends with F does not have E, you presumably want to have\n> the branch that ends at D its own identity, so\n> \n> (1) 'master' or whatever that used to end at A and now its tip is\n> at G;\n> \n> (2) the branch that ends at D whose upstream is 'master';\n> \n> (3) the branch that ends at E whose upstream is (2); and\n> \n> (4) the branch that ends at F whose upstream is (2).\n> \n> I personally do not do that, though, because you'd need to remember\n> the order in which these three branches must be rebased (i.e. (2)\n> must be done first before rebasing (3) and (4) in any order).\n\nI do occasionally have dependent topics, and use a topological sort to\norder my rebases, which solves the problem. The code I use is in:\n\n https://github.com/peff/git/blob/meta/rebase\n\n-Peff\n"}]}