Re: Marking commits as transitory for git bisect?

[Michael J Gruber <git@drmicha.warpmail.net>]

David Kastrup venit, vidit, dixit 02.12.2009 10:32:
> 
> Hi,
> 
> sometimes there are changes which would seem better to restructure into
> more than one commit, with a non-operative intermediate state.
> 
> What I am thinking of is something like
> 
> a) change an API (small but highly intricate patch warranting thorough
>    line-by-line review to make sure it's fine)
> b) adapt all existing callers (really large but utterly trivial patch)
> 
> Substructuring this change into two commits may be quite nicer for
> reviewing and following it.
> 
> Except that it breaks git bisect.  If there was a way to mark a commit
> as non-interesting, something which does not necessarily need any new
> repo features but just a convention like automatically skipping commits
> that contain the literal string [skip bisect] in the commit message,
> that would be one way to implement basic functionality like that.
> 
> A more thorough approach might also warn against partial cherrypicks or
> rebases or merges applying just part of one such a combined change.
> 
> But the main point is the ability to keep git bisect working on commit
> combinations with deliberately non-operative transitory stage.
> 

A quick solution with current git would be "replace": Say, in
A-B-C-D
you want B and C to be considered an "atom" for bisection. So, "git
replace" C by a commit C' which is B+C squashed and has A as its parent:
A-C'-D.

Alternatively, if you want this to be distributed more easily and think
of it at the time of committing, producing a DAG like

A--C'--D
 \    /
  B--C

with C' as the first parent of D may help during bisection. I.e., you
keep the detailed history on the side branch and squash it together on
the --first-parent-line, with C,C' being tree-same.

Cheers,
Michael