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