git rebase -p and patch equivalent commits

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!

On Tue, Oct 16, 2012 at 12:58 PM, Damien Robert <damien.olivier.robert+gmane@gmail.com> wrote:

If the build branch really is just a build branch, then I would probably choose this option.

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

Did you mean --hard/--keep here? Or why would you use --soft?

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