On Nov 8, 2007, at 1:54 PM, Steffen Prohaska wrote:
Do you use rebase like this in real life?
I thought of the text as background information that might
be helpful for users who want do decide wether to merge or
to rebase. The problem described may be valuable information
supporting a decision about a recommended workflow for a group
of users.
You're missing the point. Johannes suggested that you rebase *only*
for bisecting purpose. Once you find the culprit commit, throw away
your rebased stuff. I've never thought about doing this myself, but
it's a very clever way of tackling this problem. It's slightly less
convenient if you need to bisect a large portion of the history (that
involves many branches and merges) because in this case we'd like to
have a magic git-linearize-history <start-treeish> <end-treeish>.
Unless this is already easily doable with git-rebase?
So to summarize (untested):
git merge topic
make check
<omg something's broken>
git reset --hard HEAD~1 # undo the merge
git checkout -b wtf
git rebase topic master
git bisect ...
<OK I found the culprit>
git checkout master
git branch -D wtf
git merge --no-commit topic
<fix the problem>
git commit # merge done, semantic glitch fixed
Correct me if I'm wrong.
This has *nothing* to do with the fact that you use merge or rebase
to do whatever you were doing.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory