{"thread":{"id":"47801","subject":"totally confused as to what \"git bisect skip\" is supposed to do","startedAt":"2018-02-09T19:36:35Z","lastAt":"2018-02-13T13:10:25Z","messageCount":8,"participants":["Robert P. J. Day","Junio C Hamano","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"338902","messageId":"alpine.LFD.2.21.1802091431360.10982@localhost.localdomain","threadId":"47801","inReplyTo":null,"subject":"totally confused as to what \"git bisect skip\" is supposed to do","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-02-09T19:36:28Z","receivedAt":"2018-02-09T19:36:35Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"\n  all right, i'm sure i'm just being an idiot, but i always thought i\nknew what \"git bisect skip\" did and, now that i'm trying to put\ntogether a simple example, i'm utterly confused so here's a stripped\ndown example.\n\n  with linus kernel source code, start bisecting [v4.13,v4.14]:\n\n$ git bisect start v4.14 v4.13\nBisecting: 7300 revisions left to test after this (roughly 13 steps)\n[15d8ffc96464f6571ecf22043c45fad659f11bdd] Merge tag 'mmc-v4.14' of\ngit://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc\n$\n\n  now, based on how linux kernel release candidates work, i want to\nskip a sizable chunk of those revisions:\n\n$ git bisect skip v4.14-rc1..v4.14-rc2\nBisecting: 7300 revisions left to test after this (roughly 13 steps)\n[15d8ffc96464f6571ecf22043c45fad659f11bdd] Merge tag 'mmc-v4.14' of\ngit://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc\n$\n\n  i'm confused ... why, after skipping a good chunk in the interval\n[v4.13,v4.14], do i still have exactly 7300 revisions to bisect? what\nam i so hopelessly misunderstanding here?\n\nrday\n"},{"id":"338903","messageId":"xmqqo9kyvthx.fsf@gitster-ct.c.googlers.com","threadId":"47801","inReplyTo":"alpine.LFD.2.21.1802091431360.10982@localhost.localdomain","subject":"Re: totally confused as to what \"git bisect skip\" is supposed to do","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-02-09T19:43:38Z","receivedAt":"2018-02-09T19:43:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n\n>   i'm confused ... why, after skipping a good chunk in the interval\n> [v4.13,v4.14], do i still have exactly 7300 revisions to bisect? what\n> am i so hopelessly misunderstanding here?\n\nAre you really \"skipping\" a chunk in the interval?\n\nI thought that \"git bisect skip\" is a way for you to respond, when\n\"git bisect\" gave you a commit to test, saying \"sorry, I cannot test\nthat exact version, please offer me something else to test\".  And\neach time you say that, you are not narrowing the search space in\nany way, so it is understandable that the numver of candidate bad\ncommits will not decrease.\n\n\n"},{"id":"338905","messageId":"alpine.LFD.2.21.1802091447540.14489@localhost.localdomain","threadId":"47801","inReplyTo":"xmqqo9kyvthx.fsf@gitster-ct.c.googlers.com","subject":"Re: totally confused as to what \"git bisect skip\" is supposed to do","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-02-09T19:51:51Z","receivedAt":"2018-02-09T19:51:58Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Fri, 9 Feb 2018, Junio C Hamano wrote:\n\n> \"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n>\n> >   i'm confused ... why, after skipping a good chunk in the\n> > interval [v4.13,v4.14], do i still have exactly 7300 revisions to\n> > bisect? what am i so hopelessly misunderstanding here?\n>\n> Are you really \"skipping\" a chunk in the interval?\n\n  i don't know ... am i? how should i interpret the man page?\n\n> I thought that \"git bisect skip\" is a way for you to respond, when\n> \"git bisect\" gave you a commit to test, saying \"sorry, I cannot test\n> that exact version, please offer me something else to test\".  And\n> each time you say that, you are not narrowing the search space in\n> any way, so it is understandable that the number of candidate bad\n> commits will not decrease.\n\n  i caught that part of the man page, but i'm trying to understand\nwhat i'm reading here:\n\nhttps://blog.smart.ly/2015/02/03/git-bisect-debugging-with-feature-branches/\n\n  particularly this suggestion:\n\n  $ git bisect start master 75369f4a4c026772242368d870872562a3b693cb\n\n  $ for rev in $(git rev-list\n    75369f4a4c026772242368d870872562a3b693cb..master --merges\n    --first-parent); do\n    >   git rev-list $rev^2 --not $rev^\n    > done | xargs git bisect skip\n\nmy interpretation of that page is how, after starting a bisection, one\ncan use \"git bisect skip\" to explicitly disqualify a sizable number of\ncommits from consideration, speeding up the subsequent bisection.\n\n  if that's not what that web page is describing, then what *is* it\ntalking about?\n\nrday\n"},{"id":"339076","messageId":"alpine.LFD.2.21.1802120522580.17810@localhost.localdomain","threadId":"47801","inReplyTo":"xmqqo9kyvthx.fsf@gitster-ct.c.googlers.com","subject":"Re: totally confused as to what \"git bisect skip\" is supposed to do","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-02-12T10:44:54Z","receivedAt":"2018-02-12T10:45:05Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Fri, 9 Feb 2018, Junio C Hamano wrote:\n\n> \"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n>\n> >   i'm confused ... why, after skipping a good chunk in the interval\n> > [v4.13,v4.14], do i still have exactly 7300 revisions to bisect? what\n> > am i so hopelessly misunderstanding here?\n>\n> Are you really \"skipping\" a chunk in the interval?\n>\n> I thought that \"git bisect skip\" is a way for you to respond, when\n> \"git bisect\" gave you a commit to test, saying \"sorry, I cannot test\n> that exact version, please offer me something else to test\".  And\n> each time you say that, you are not narrowing the search space in\n> any way, so it is understandable that the numver of candidate bad\n> commits will not decrease.\n\n  this might be an issue of terminology, then, as \"man git-bisect\"\nclearly suggests you can skip a range:\n\n    You can also skip a range of commits, instead of just one\n    commit, using range notation. For example:\n\n           $ git bisect skip v2.5..v2.6\n\n    This tells the bisect process that no commit after v2.5, up to\n    and including v2.6, should be tested.\n\nmy issue (if this is indeed an issue) is that if i select to skip a\nsizable range of commits to test, should that not result in git bisect\ntelling me it now has far fewer revisions to test? if i, in fact,\nmanage to \"disqualify\" a number of commits from testing, is there no\nvisual confirmation that i now have fewer commits to test?\n\nrday\n"},{"id":"339082","messageId":"CAP8UFD03TDGBU3t3+m2OmhyJt6sNcPhMZ2ejzufX3x-_1EEDHA@mail.gmail.com","threadId":"47801","inReplyTo":"alpine.LFD.2.21.1802120522580.17810@localhost.localdomain","subject":"Re: totally confused as to what \"git bisect skip\" is supposed to do","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-02-12T16:21:23Z","receivedAt":"2018-02-12T16:21:30Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Feb 12, 2018 at 11:44 AM, Robert P. J. Day\n<rpjday@crashcourse.ca> wrote:\n> On Fri, 9 Feb 2018, Junio C Hamano wrote:\n>\n>> \"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n>>\n>> >   i'm confused ... why, after skipping a good chunk in the interval\n>> > [v4.13,v4.14], do i still have exactly 7300 revisions to bisect? what\n>> > am i so hopelessly misunderstanding here?\n>>\n>> Are you really \"skipping\" a chunk in the interval?\n>>\n>> I thought that \"git bisect skip\" is a way for you to respond, when\n>> \"git bisect\" gave you a commit to test, saying \"sorry, I cannot test\n>> that exact version, please offer me something else to test\".  And\n>> each time you say that, you are not narrowing the search space in\n>> any way, so it is understandable that the numver of candidate bad\n>> commits will not decrease.\n>\n>   this might be an issue of terminology, then, as \"man git-bisect\"\n> clearly suggests you can skip a range:\n>\n>     You can also skip a range of commits, instead of just one\n>     commit, using range notation. For example:\n>\n>            $ git bisect skip v2.5..v2.6\n>\n>     This tells the bisect process that no commit after v2.5, up to\n>     and including v2.6, should be tested.\n\nYeah, I think this is kind of a terminology related.\n\nFirst when git bisect says \"Bisecting: XXX revisions left to test\nafter this\" it doesn't mean that all those revisions left will\nactually be tested, as git bisect's purpose is to avoid testing as\nmany revisions as possible.\n\nSo the XXX revisions are actually the revisions that possibly contain\nthe first bad commit.\n\nAnd, as Junio wrote, when you tell git bisect that you cannot test\nsome revisions, it doesn't mean that those revisions cannot contain\nthe first bad commit.\n\n> my issue (if this is indeed an issue) is that if i select to skip a\n> sizable range of commits to test, should that not result in git bisect\n> telling me it now has far fewer revisions to test? if i, in fact,\n> manage to \"disqualify\" a number of commits from testing, is there no\n> visual confirmation that i now have fewer commits to test?\n\nI hope that the above clarification I gave is enough, but maybe the\nfollowing will help you.\n\nIf you cannot test let's say 20 commits because there is build problem\nin those commits, and in the end Git tells you that the first bad\ncommit could be any of 3 commits, 2 of them that were previously\nmarked with skip, then you could still, if you wanted, fix those\ncommits, so that they can be built and test them.\n\nSo yeah if we only talk about the current bisection, the skipped\ncommits will not be tested, but if we talk about completely finishing\nthe bisection and finding the first bad commit, then those commits\ncould still be tested.\n"},{"id":"339191","messageId":"alpine.LFD.2.21.1802130712260.15482@localhost.localdomain","threadId":"47801","inReplyTo":"CAP8UFD03TDGBU3t3+m2OmhyJt6sNcPhMZ2ejzufX3x-_1EEDHA@mail.gmail.com","subject":"Re: totally confused as to what \"git bisect skip\" is supposed to do","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-02-13T12:28:08Z","receivedAt":"2018-02-13T12:28:17Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Mon, 12 Feb 2018, Christian Couder wrote:\n\n> On Mon, Feb 12, 2018 at 11:44 AM, Robert P. J. Day\n> <rpjday@crashcourse.ca> wrote:\n> > On Fri, 9 Feb 2018, Junio C Hamano wrote:\n> >\n> >> \"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n> >>\n> >> >   i'm confused ... why, after skipping a good chunk in the interval\n> >> > [v4.13,v4.14], do i still have exactly 7300 revisions to bisect? what\n> >> > am i so hopelessly misunderstanding here?\n> >>\n> >> Are you really \"skipping\" a chunk in the interval?\n> >>\n> >> I thought that \"git bisect skip\" is a way for you to respond, when\n> >> \"git bisect\" gave you a commit to test, saying \"sorry, I cannot test\n> >> that exact version, please offer me something else to test\".  And\n> >> each time you say that, you are not narrowing the search space in\n> >> any way, so it is understandable that the numver of candidate bad\n> >> commits will not decrease.\n> >\n> >   this might be an issue of terminology, then, as \"man git-bisect\"\n> > clearly suggests you can skip a range:\n> >\n> >     You can also skip a range of commits, instead of just one\n> >     commit, using range notation. For example:\n> >\n> >            $ git bisect skip v2.5..v2.6\n> >\n> >     This tells the bisect process that no commit after v2.5, up to\n> >     and including v2.6, should be tested.\n>\n> Yeah, I think this is kind of a terminology related.\n>\n> First when git bisect says \"Bisecting: XXX revisions left to test\n> after this\" it doesn't mean that all those revisions left will\n> actually be tested, as git bisect's purpose is to avoid testing as\n> many revisions as possible.\n>\n> So the XXX revisions are actually the revisions that possibly\n> contain the first bad commit.\n>\n> And, as Junio wrote, when you tell git bisect that you cannot test\n> some revisions, it doesn't mean that those revisions cannot contain\n> the first bad commit.\n>\n> > my issue (if this is indeed an issue) is that if i select to skip\n> > a sizable range of commits to test, should that not result in git\n> > bisect telling me it now has far fewer revisions to test? if i, in\n> > fact, manage to \"disqualify\" a number of commits from testing, is\n> > there no visual confirmation that i now have fewer commits to\n> > test?\n>\n> I hope that the above clarification I gave is enough, but maybe the\n> following will help you.\n>\n> If you cannot test let's say 20 commits because there is build\n> problem in those commits, and in the end Git tells you that the\n> first bad commit could be any of 3 commits, 2 of them that were\n> previously marked with skip, then you could still, if you wanted,\n> fix those commits, so that they can be built and test them.\n>\n> So yeah if we only talk about the current bisection, the skipped\n> commits will not be tested, but if we talk about completely\n> finishing the bisection and finding the first bad commit, then those\n> commits could still be tested.\n\n  ok, i'll give this more thought later in the week when i have the\ntime, but is there a simple expression (using \"gitrevisions\") that\ndefines the set of revisions to be tested by bisection if i define the\nsearch space between <GOOD> and <BAD>?\n\n  consider the following history:\n\n               ... 50000 commits ... (feature branch)\n             /                      ^\n            /                        \\\n           v                          \\\n  A  <--  B <-- <GOOD> <-- D <-- E <-- F <-- <BAD>\n\nso imagine branching at B, creating a massively lengthy feature\nbranch, and merging it back to master at F. now imagine i know \"GOOD\"\nis a good revision, and \"BAD\" is broken. according to the above, the\noffending commit could be any of D, E, or any of the 50,000 commits on\nthe feature branch, correct? so if i had the above commit history,\nwould:\n\n  $ git bisect start <BAD> <GOOD>\n\ntell me i have 50,002 revisions to test? am i making sense here?\n\nrday\n\np.s. i suspect i should RTFS to see exactly how git bisect does its\nwork.\n"},{"id":"339193","messageId":"CAP8UFD0hRS_VFpHT-S=Sn7mr4pE+FseUm9nTVEOvLBF-dG9FPA@mail.gmail.com","threadId":"47801","inReplyTo":"alpine.LFD.2.21.1802130712260.15482@localhost.localdomain","subject":"Re: totally confused as to what \"git bisect skip\" is supposed to do","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-02-13T12:59:22Z","receivedAt":"2018-02-13T12:59:32Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Feb 13, 2018 at 1:28 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:\n>\n> p.s. i suspect i should RTFS to see exactly how git bisect does its\n> work.\n\nYou might want to read https://git-scm.com/docs/git-bisect-lk2009.html\nbefore reading the source code.\n"},{"id":"339195","messageId":"alpine.LFD.2.21.1802130810001.17912@localhost.localdomain","threadId":"47801","inReplyTo":"CAP8UFD0hRS_VFpHT-S=Sn7mr4pE+FseUm9nTVEOvLBF-dG9FPA@mail.gmail.com","subject":"Re: totally confused as to what \"git bisect skip\" is supposed to do","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2018-02-13T13:10:17Z","receivedAt":"2018-02-13T13:10:25Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"On Tue, 13 Feb 2018, Christian Couder wrote:\n\n> On Tue, Feb 13, 2018 at 1:28 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:\n> >\n> > p.s. i suspect i should RTFS to see exactly how git bisect does its\n> > work.\n>\n> You might want to read\n> https://git-scm.com/docs/git-bisect-lk2009.html before reading the\n> source code.\n\n  ah, excellent, thanks very much.\n\nrday\n"}]}