git rebase -p and patch equivalent commits

git rebase -p and patch equivalent commits

[Damien Robert]

Hi all,
I was wondering if you had any tips on the following workflow:
I work on an experimental feature branch of a project. I have some patches
that I implement in branch patch1 and patch2 on top of the feature branch.
I test if they both work together by merging patch1 and patch2 into a build
branch:
    mkdir build && cd build
    git init
    echo a > a && git add a && git commit -am a
    git branch feature
    git co -b patch1
    echo b > b && git add b && git commit -am b
    git co -b patch2 feature
    echo c > c && git add c && git commit -am c
    git co -b build feature
    git merge --no-edit patch1 patch2
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.
   This start to get complicated if I have some commits in build after the
   merge, I will then need to rebase them on top of the new merge. And for
   a more complicated layout it will get pretty hard to recreate it
   automatically.
2) I can rebase -p the build branch first, and then reset --soft patch1 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.

So my question is: does it look like a sensible approach? Is there an
easier way I am missing?

Thanks!

Re: git rebase -p and patch equivalent commits

[Martin von Zweigbergk]

On Tue, Oct 16, 2012 at 12:58 PM, Damien Robert
<damien.olivier.robert+gmane@gmail.com> 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".