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
    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
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?


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to