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