On Fri, 9 Feb 2018, Junio C Hamano wrote: > "Robert P. J. Day" <rpjday@xxxxxxxxxxxxxx> writes: > > > i'm confused ... why, after skipping a good chunk in the > > interval [v4.13,v4.14], do i still have exactly 7300 revisions to > > bisect? what am i so hopelessly misunderstanding here? > > Are you really "skipping" a chunk in the interval? i don't know ... am i? how should i interpret the man page? > I thought that "git bisect skip" is a way for you to respond, when > "git bisect" gave you a commit to test, saying "sorry, I cannot test > that exact version, please offer me something else to test". And > each time you say that, you are not narrowing the search space in > any way, so it is understandable that the number of candidate bad > commits will not decrease. i caught that part of the man page, but i'm trying to understand what i'm reading here: https://blog.smart.ly/2015/02/03/git-bisect-debugging-with-feature-branches/ particularly this suggestion: $ git bisect start master 75369f4a4c026772242368d870872562a3b693cb $ for rev in $(git rev-list 75369f4a4c026772242368d870872562a3b693cb..master --merges --first-parent); do > git rev-list $rev^2 --not $rev^ > done | xargs git bisect skip my interpretation of that page is how, after starting a bisection, one can use "git bisect skip" to explicitly disqualify a sizable number of commits from consideration, speeding up the subsequent bisection. if that's not what that web page is describing, then what *is* it talking about? rday
