On Fri, 9 Feb 2018, Junio C Hamano wrote:

> "Robert P. J. Day" <rpj...@crashcourse.ca> 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:


  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?


Reply via email to