Fixing rebase rather than avoiding it

[Stephen J. Turnbull]

Óscar Fuentes writes:
 > "Stephen J. Turnbull" <stephen at xemacs.org> writes:
 > 
 > [snip]
 > 
 > >  > If you want to use bisect, git forces you too make all commits
 > >  > bisectable.
 > >
 > > No, it does not.  Like Mercurial it supports both "bisect skip" and a
 > > return code of 125 from the run script.
 > 
 > I know. Please see my response to Teemu Likonen.

Which is irrelevant to a comparison of git bisect and bzr bisect as
far as I can see.  You'd be in great pain bisecting with bzr, too, if
any nonnegligible fraction of your commits are bogus.

It's true that bzr makes it easy to restrict yourself to merge
commits, and that would be hard to implement robustly in a git bisect
run script.  On the other hand, git provides very fast and flexible
DAG mapping tools, and it would be efficient and straightforward to
mark all non-merge commits as skips.  So what it comes down to is that
bzr provides an often convenient but relatively inflexible UI, while
git provides a "some assembly required" toolkit.  A matter of taste, I
think, not a matter of capability.