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
Attachment:
PGP.sig
Description: This is a digitally signed message part
