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