{"thread":{"id":"31839","subject":"git rebase -p and patch equivalent commits","startedAt":"2012-10-16T19:58:50Z","lastAt":"2012-10-17T05:13:28Z","messageCount":2,"participants":["Damien Robert","Martin von Zweigbergk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"201386","messageId":"k5ke9q$gom$1@ger.gmane.org","threadId":"31839","inReplyTo":null,"subject":"git rebase -p and patch equivalent commits","fromName":"Damien Robert","fromEmail":"damien.olivier.robert+gmane@gmail.com","sentAt":"2012-10-16T19:58:50Z","receivedAt":"2012-10-16T19:58:50Z","isPatch":false,"sender":{"key":"damien.olivier.robert+gmane@gmail.com","avatar":null},"body":"Hi all,\nI was wondering if you had any tips on the following workflow:\nI work on an experimental feature branch of a project. I have some patches\nthat I implement in branch patch1 and patch2 on top of the feature branch.\nI test if they both work together by merging patch1 and patch2 into a build\nbranch:\n    mkdir build && cd build\n    git init\n    echo a > a && git add a && git commit -am a\n    git branch feature\n    git co -b patch1\n    echo b > b && git add b && git commit -am b\n    git co -b patch2 feature\n    echo c > c && git add c && git commit -am c\n    git co -b build feature\n    git merge --no-edit patch1 patch2\nNow feature is rebased against master. How would you rebase the branches\npatch1, patch2 and build so that they keep the same layout?\n\nI tried to rebase patch1 and patch2, hoping that rebase -p build would use\nthe rebased commits for the merge but it creates new commits (that are\npatch equivalents to patch1 and patch2) and merge them.\n\nSo I can think of two ways to proceed:\n1) only rebase patch1 and patch2, and then remerge them again in build.\n   This start to get complicated if I have some commits in build after the\n   merge, I will then need to rebase them on top of the new merge. And for\n   a more complicated layout it will get pretty hard to recreate it\n   automatically.\n2) I can rebase -p the build branch first, and then reset --soft patch1 and\n   patch2 so that they point to the right commits in the rebased branch.\n   This way looks easier to do with more complicated layout, I just need to\n   find a good way of finding where the rebased commits for patch1 and\n   patch2 are, and I was thinking of using notes for that.\n\nSo my question is: does it look like a sensible approach? Is there an\neasier way I am missing?\n\nThanks!\n"},{"id":"201400","messageId":"CANiSa6iecBnnjqcfZjQTrhz0-_=LO_AQpDz=J3aR1==6TB3M3Q@mail.gmail.com","threadId":"31839","inReplyTo":"k5ke9q$gom$1@ger.gmane.org","subject":"Re: git rebase -p and patch equivalent commits","fromName":"Martin von Zweigbergk","fromEmail":"martinvonz@gmail.com","sentAt":"2012-10-17T05:13:28Z","receivedAt":"2012-10-17T05:13:28Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Tue, Oct 16, 2012 at 12:58 PM, Damien Robert\n<damien.olivier.robert+gmane@gmail.com> wrote:\n> Now feature is rebased against master. How would you rebase the branches\n> patch1, patch2 and build so that they keep the same layout?\n>\n> I tried to rebase patch1 and patch2, hoping that rebase -p build would use\n> the rebased commits for the merge but it creates new commits (that are\n> patch equivalents to patch1 and patch2) and merge them.\n>\n> So I can think of two ways to proceed:\n> 1) only rebase patch1 and patch2, and then remerge them again in build.\n\nIf the build branch really is just a build branch, then I would\nprobably choose this option.\n\n>    This start to get complicated if I have some commits in build after the\n>    merge\n\nWhat would such commits contain? Is it something related to your build\nsystem that you can automate? If not, should they perhaps rather have\nbeen included in one of the patch branches? Or are they related to\ninteractions between the patch branches? If the latter, I would\nprobably serialize the dependent branches (e.g. basing \"patch2\" on\n\"patch1\").\n\n> 2) I can rebase -p the build branch first, and then reset --soft patch1\n\nDid you mean --hard/--keep here? Or why would you use --soft?\n\n>    and\n>    patch2 so that they point to the right commits in the rebased branch.\n>    This way looks easier to do with more complicated layout, I just need to\n>    find a good way of finding where the rebased commits for patch1 and\n>    patch2 are, and I was thinking of using notes for that.\n\nI don't quite understand why you would want to do that if the build\nbranch is just to make sure test pass on the merged result, but, yes,\nthis method would probably be easier if you do need to keep both the\nbuild branch and the patchX branches up to date. Which branch do you\nactively work on at this point? Both the build branch and the patchX\nbranches? Is it that you have sent patch1 and patch2 for review and\nyou want to base your next topic on the merged result? I assume not,\nsince you said it was a \"build\" branch. But if that was the case (i.e.\nsomewhat active development on build, patch1 and patch2 (perhaps due\nto review comments)), I would probably still rebase one branch at a\ntime, recreate the merge (possibly using rerere), and then \"rebase\n--onto new-merge old-merge build\".\n"}]}