Fixing rebase rather than avoiding it

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

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

If the commits on the left part of the DAG are bisectable, it is good
enough. The merged history may fail tests, break the build, whatever,
and it is fine. IMO this is a great advantage of having a privileged
path on the DAG.

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

This is impractical. First, a non-merge commit may belong to the
bisectable path. Second, a merge commit may belong to the non-bisectable
path.

[snip]