Hi Jim, Jim Cromie wrote: > if git bisect were to recognize --skip-bisect in the subject line > (or in commit-message somewhere, say top or bottom), > then bisection could proceed silently past such commits. In addition to Ram’s suggestion, you might want to look into ‘git replace’[1]. It can be useful when the broken commits have already been published. It works like this: git replace <bad commit> <bad commit>^ and then ‘git bisect’ and lower-level commands like git show and checkout will silently substitute the parent of the broken commit when ever you refer to it. You can publish the resulting “replace refs” in the refs/replace/* namespace and anyone who explicitly chooses to fetch them will be able to see the same effect. Two problems: - bisect skip is a bit more sophisticated (read: better) than just substituting a parent, especially when the commit to be skipped is a merge. So it might still make sense to teach bisect to respect a refs/notes/skip-bisect note that requests for it to skip a specific ref. One can try this out by making an appropriate wrapper script for ‘git bisect next’ (using ‘git notes’). - replace refs are a little too powerful. It would be nicer to by able to use ‘git replace --refs=refs/replace/bisect/’ and ‘GIT_REPLACE_REFS=refs/replace/bisect/ git bisect’ to make them take effect only when needed. In other words, it would be nicer if “git replace” were configurable in the same way as “git notes” is. One can get something like that effect by using git for-each-ref and git update-ref to rename replace refs into place only when needed. [1] http://www.kernel.org/pub/software/scm/git/docs/git-bisect-lk2009.html#_git_replace -- 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