On Tue, Oct 16, 2012 at 12:58 PM, Damien Robert <damien.olivier.robert+gmane@xxxxxxxxx> wrote: > Now feature is rebased against master. How would you rebase the branches > patch1, patch2 and build so that they keep the same layout? > > I tried to rebase patch1 and patch2, hoping that rebase -p build would use > the rebased commits for the merge but it creates new commits (that are > patch equivalents to patch1 and patch2) and merge them. > > So I can think of two ways to proceed: > 1) only rebase patch1 and patch2, and then remerge them again in build. If the build branch really is just a build branch, then I would probably choose this option. > This start to get complicated if I have some commits in build after the > merge What would such commits contain? Is it something related to your build system that you can automate? If not, should they perhaps rather have been included in one of the patch branches? Or are they related to interactions between the patch branches? If the latter, I would probably serialize the dependent branches (e.g. basing "patch2" on "patch1"). > 2) I can rebase -p the build branch first, and then reset --soft patch1 Did you mean --hard/--keep here? Or why would you use --soft? > and > patch2 so that they point to the right commits in the rebased branch. > This way looks easier to do with more complicated layout, I just need to > find a good way of finding where the rebased commits for patch1 and > patch2 are, and I was thinking of using notes for that. I don't quite understand why you would want to do that if the build branch is just to make sure test pass on the merged result, but, yes, this method would probably be easier if you do need to keep both the build branch and the patchX branches up to date. Which branch do you actively work on at this point? Both the build branch and the patchX branches? Is it that you have sent patch1 and patch2 for review and you want to base your next topic on the merged result? I assume not, since you said it was a "build" branch. But if that was the case (i.e. somewhat active development on build, patch1 and patch2 (perhaps due to review comments)), I would probably still rebase one branch at a time, recreate the merge (possibly using rerere), and then "rebase --onto new-merge old-merge build". -- 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