From: Benoit Sigoure <tsuna@lrde.epita.fr>
Date: Thu, 08 Nov 2007 14:51:00 GMT
Subject: Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
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:

> 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