So I suggest to use '--bisect-refs' instead of '--bisect' as the new bisect revision machinery option, because otherwise I think we get a regression when we call "git rev-list --bisect BAD --not GOOD" and we are already bisecting with bisect refs different than BAD and GOOD. This also simplifies the code a little bit. I had a look at using '--bisect-refs' in the git bisect helper instead of collecting the good and bad refs in bisect.c::read_bisect_refs(), but I gave up because I think we need the good and bad refs anyway for other purposes like checking that all good refs are ancestor of the bad ref. So I think we would not gain much if anything there. If this is ok then the next steps I can do is add some documentation and tests for the new '--bisect-refs' option. Christian Couder (3): t6030: show "rev-list --bisect" breakage when bisecting revision: change '--bisect' rev machinery argument to 'bisect-refs' bisect: simplify calling visualizer using '--bisect-refs' builtin-rev-list.c | 2 -- builtin-rev-parse.c | 4 ++-- git-bisect.sh | 3 +-- revision.c | 5 ++--- revision.h | 1 - t/t6030-bisect-porcelain.sh | 13 +++++++++++++ 6 files changed, 18 insertions(+), 10 deletions(-) -- 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