On Tue, Aug 2, 2016 at 11:00 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Oleg Taranenko <olegtaranenko@xxxxxxxxx> writes: > >> First, assuming the common ancestor is GOOD based on the fact that >> some descendant given as GOOD is pretty bad idea. > > What you claim is fundamentally incompatible with the way "bisect" > works as a O(log(n)) operation. It is likely that your definition > of Good for the purpose of your bug-hunting needs to be rethought if > you want to take advantage of "bisect". Without context it sounds a bit silly, agree. Context was, maybe not explicit stated, based on previous discussion: If we looking in direct path G..B, of course bisect should show its power O(log(n)); BUT, assuming that any predecessor (G~1/G~2...)...is good if this commit G~n has direct path to B, but not via G, (as git does now) is wrong. This is my concern. Ever G~1 may have not feature we are looking for, then we must treated it as BAD in current git bisect session. To be sure we require additional evidence and just opening a new bisect roundrips in case G~n is GOOD. If G~n confirmed as BAD, we need to stop looking in this path (no need to find transition BAG -> BAD) and switch to another possible common ancestor (or next octopus parent) In merge-based development (opposite to rebased one) this can happen very easy >> I have another request to get git bisect more user-friendly, regarding >> rolling back last step or steps, if accidentally 'git bisect bad' or >> 'good' was wrong entered, but I think it worth for another thread. > > Are you aware that you can check $GIT_DIR/BISECT_LOG and replay it > to recreate any previous state of the bisection? That would > probably help. git bisect log / replay is not convenient. First we need to find place where to keep log file (not forget its name), then edit it. If I'm not sure how many steps I did a mistake the troubles doubles, What are obstacles to implement git bisect back ? or git bisect back --steps=2 I don't think it will be significant change in code. It would be a great help especially if hunting in multiply logically loose-coupled repos. Say searching bug in application, possible caused elusive changes on several dependent libraries. -- 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