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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Thu, 8 Nov 2007, Benoit Sigoure wrote:

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

Just to clear things up: it was the other Johannes who suggested it.

But I strongly advise not to rebase before bisecting, since you could very 
well end up changing the behaviour of the program by rebasing it.  Even to 
a point where you cannot bisect it any longer, for example when the merge 
of two branches contains an important fix without which the combined 
branches (or even parts of them) will not even compile.

Last time I checked, however, bisect worked like a charm even on 
a history with complicated ancestry.

Ciao,
Dscho

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux