Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"

From: Benoit Sigoure <tsuna@lrde.epita.fr>
Date: Nov 8, 2007, 14:51 UTC
Message-ID: <5498B368-053A-424E-B901-A55B66FF5801@lrde.epita.fr>
In-Reply-To: <97F64156-A457-4BC1-84BE-108369FFD18C@zib.de>

On Nov 8, 2007, at 1:54 PM, Steffen Prohaska wrote:

Show 7 quoted lines

> 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