{"thread":{"id":"61183","subject":"Allow git bisect to auto-skip","startedAt":"2024-03-22T22:18:49Z","lastAt":"2024-03-28T08:01:06Z","messageCount":14,"participants":["Olliver Schinagl","Junio C Hamano","Stefan Haller","Christian Couder","rsbecker@nexbridge.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"491277","messageId":"3d835c4b-d026-4c6a-b68e-6989a7a2065f@schinagl.nl","threadId":"61183","inReplyTo":null,"subject":"Allow git bisect to auto-skip","fromName":"Olliver Schinagl","fromEmail":"oliver@schinagl.nl","sentAt":"2024-03-22T22:18:47Z","receivedAt":"2024-03-22T22:18:49Z","isPatch":false,"sender":{"key":"oliver@schinagl.nl","avatar":"https://gravatar.com/avatar/abb8ef5f9b23563b7703a4114da6f9bd6e7f6d7e8e0296677547b20ff7740c56?d=mp&s=160"},"body":"In some cases, we know a commit will always break bisect. This is bad \nand evil but sometimes needed.\n\nAn example, in my particular case, when OpenWRT does a kernel bump, \npatches and config files get copied to the new version. This is fine, \nbut there is not git copy (one could also see that as an individual \nfeature request which would solve the actual issue for now :p). Since \nthe files are copied, git treats them as new files, without history. \nThis makes tracking history almost impossible (config-4.14 -> config \n5.15 -> config 6.6 etc). People have found out, there's some tricks to \napply where we can make git not see the copy as such, and we'll have our \nhistory of both files [0]. In short, this hack is used to create two \ncommits.\n\ngit checkout -b _tmp\ngit mv old new\ngit commit -m 'copy old to new' -m 'GIT_SKIP_BISECT'\ngit checkout HEAD~ old\ngit commit -m 'restore old'\ngit switch _tmp\ngit merge _tmp\n\nand to remove the ugly merge commit\n\ngit rebase HEAD~1\n\nwhich surely is a hack :p\n\nBut, it's a `git cp` if you will.\n\nNow this does break git bisect, when the commit with the move comes in, \nthings are broken until the next commit. It would be very nice if we can \nhave a special marker keyword (GIT_SKIP_BISECT) in the commit message \nfor example, to force git bisect to just skip this commit. It will fail, \nit is designed to fail.\n\nThere's probably also other very useful cases, but this is just one example.\n\nAnd hey, if this leads to two patches, where a second one introduces \n`git cp` I'd be even more happy :)\n\nOlliver\n\n[0]: https://github.com/openwrt/openwrt/blob/main/scripts/kernel_bump.sh\n"},{"id":"491278","messageId":"xmqqwmptzyny.fsf@gitster.g","threadId":"61183","inReplyTo":"3d835c4b-d026-4c6a-b68e-6989a7a2065f@schinagl.nl","subject":"Re: Allow git bisect to auto-skip","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-22T22:31:29Z","receivedAt":"2024-03-22T22:31:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Olliver Schinagl <oliver@schinagl.nl> writes:\n\n> In some cases, we know a commit will always break bisect. This is bad\n> and evil but sometimes needed.\n> ...\n> git commit -m 'copy old to new' -m 'GIT_SKIP_BISECT'\n> ...\n\nIf \"I want a bisect to skip any commit that has 'Skip Me' in its\nsubject\" is the case, perhaps your \"git bisect run\" script can say\n\n    #!/bin/sh\n\n    case \"$(git show -s --oneline)\" in\n    *\"Skip Me\"*) exit 125 ;;\n    esac\n\n    ... your test script body comes here ...\n    if test successful\n    then\n        exit 0\n    else\n        exit 1\n    fi\n\nThe _clue_ to mark a commit to be skipped does not have to be\nhardcoded commit title.  It often is discovered that a commit\nbreaks bisection after the fact and it is not feasible to rebase\nall the history after the commit.  Maybe an approach more suitable\nin such a situation would attach a note to such untestable commits\nafter the fact, and check if such a note is attached at the\nbeginning of \"git bisect run\" script and exit with 125.\n\nAnd a new \"git bisect --skip-when <condition>\" option can be added to\nmanual bisection process.  The <condition> part would contain\nsomething like\n\n    case \"$(git show -s --oneline)\" in\n    *\"Skip Me\"*) exit 125 ;;\n    esac\n\ntaken from the above illustration.\n\nBut I am not sure what end result you are trying to achieve, so the\nabove are random collection of ideas.  Turning them into a patch is\nleft as an exercise to readers.\n\n\n\n"},{"id":"491288","messageId":"CC68481D-E993-49F2-8941-8F5FA080B139@schinagl.nl","threadId":"61183","inReplyTo":"xmqqwmptzyny.fsf@gitster.g","subject":"Re: Allow git bisect to auto-skip","fromName":"Olliver Schinagl","fromEmail":"oliver@schinagl.nl","sentAt":"2024-03-23T01:59:59Z","receivedAt":"2024-03-23T02:00:06Z","isPatch":false,"sender":{"key":"oliver@schinagl.nl","avatar":"https://gravatar.com/avatar/abb8ef5f9b23563b7703a4114da6f9bd6e7f6d7e8e0296677547b20ff7740c56?d=mp&s=160"},"body":"Hey Junio,\n\nOn March 22, 2024 11:31:29 p.m. GMT+01:00, Junio C Hamano <gitster@pobox.com> wrote:\n>Olliver Schinagl <oliver@schinagl.nl> writes:\n>\n>> In some cases, we know a commit will always break bisect. This is bad\n>> and evil but sometimes needed.\n>> ...\n>> git commit -m 'copy old to new' -m 'GIT_SKIP_BISECT'\n>> ...\n>\n>If \"I want a bisect to skip any commit that has 'Skip Me' in its\n>subject\" is the case, perhaps your \"git bisect run\" script can say\n>\n>    #!/bin/sh\n>\n>    case \"$(git show -s --oneline)\" in\n>    *\"Skip Me\"*) exit 125 ;;\n>    esac\n>\n>    ... your test script body comes here ...\n>    if test successful\n>    then\n>        exit 0\n>    else\n>        exit 1\n>    fi\n>\n\nThis is a nice way to wrap got bisect, but from a UX point of view, having native support from the got client would be much nicer. E.g. the user doesn't have to learn about special scripts. I'd argue, if we can do it the same way everywhere (I.e. shipping such a script as part of the got distro), why not handle it nativily.\n\nThe magic word could be a default with an override in the gitconfig.\n\n>The _clue_ to mark a commit to be skipped does not have to be\n>hardcoded commit title.  It often is discovered that a commit\n>breaks bisection after the fact and it is not feasible to rebase\n>all the history after the commit.  Maybe an approach more suitable\n>in such a situation would attach a note to such untestable commits\n>after the fact, and check if such a note is attached at the\n>beginning of \"git bisect run\" script and exit with 125.\n>\n>And a new \"git bisect --skip-when <condition>\" option can be added to\n>manual bisection process.  The <condition> part would contain\n>something like\n>\n>    case \"$(git show -s --oneline)\" in\n>    *\"Skip Me\"*) exit 125 ;;\n>    esac\n>\n>taken from the above illustration.\n>\n\nI've read the notes solution from 13 years ago ;) and I do like the elegance. But I think there's two cases. One during the fact, when you know this will be an issue andere in deed ons after the fact.\n\nI'll admit, I was oblivious by git notes, and will read up on it now. Always using a note for this feature does make sense, as its part of the repository.\n\n\n>But I am not sure what end result you are trying to achieve, so the\n>above are random collection of ideas.  Turning them into a patch is\n>left as an exercise to readers.\n\nIn the end, is it (internally) even possible for got bisect to check this, and would a patch that handles this 'behind the scenes' be accepted, without the user having to install special tooling (scripts)?\n\nHaving said that, on a different note is 'git copy' feasable? E.g. git CP old new, where both files share the same history?\n\nOlliver\n"},{"id":"491298","messageId":"01e09c64-4d62-406d-85fe-9fb77939cf63@haller-berlin.de","threadId":"61183","inReplyTo":"xmqqwmptzyny.fsf@gitster.g","subject":"Re: Allow git bisect to auto-skip","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2024-03-23T13:51:21Z","receivedAt":"2024-03-23T14:00:55Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 22.03.24 23:31, Junio C Hamano wrote:\n> It often is discovered that a commit\n> breaks bisection after the fact and it is not feasible to rebase\n> all the history after the commit.\n\nThis reminds me of a similar problem with git blame, for which we have\nthe blame.ignoreRevsFile config to work around it. Couldn't there be a\nsimilar mechanism for bisect, e.g. bisect.skipRevsFile?\n\n-Stefan\n\n"},{"id":"491309","messageId":"xmqqle68x008.fsf@gitster.g","threadId":"61183","inReplyTo":"01e09c64-4d62-406d-85fe-9fb77939cf63@haller-berlin.de","subject":"Re: Allow git bisect to auto-skip","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-23T18:43:03Z","receivedAt":"2024-03-23T18:43:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Haller <lists@haller-berlin.de> writes:\n\n> On 22.03.24 23:31, Junio C Hamano wrote:\n>> It often is discovered that a commit\n>> breaks bisection after the fact and it is not feasible to rebase\n>> all the history after the commit.\n>\n> This reminds me of a similar problem with git blame, for which we have\n> the blame.ignoreRevsFile config to work around it. Couldn't there be a\n> similar mechanism for bisect, e.g. bisect.skipRevsFile?\n\nA Very good point.  If a breakage of a commit is \"this does not even\nbuild\" kind of breakage, such a mechanism would be an excellent fit.\n\nBut if a breakage is \"only this particular test fails and we know\nthe reason why it fails has nothing to do with the bug we are\nchasing\", then compiling such a fixed list of commits, or pointing\nat such a list with a configuration variable, would not work very\nwell, I am afraid.\n\nThanks.\n"},{"id":"491319","messageId":"4cf100aa-4239-4377-b20a-7c90443fb405@schinagl.nl","threadId":"61183","inReplyTo":"xmqqle68x008.fsf@gitster.g","subject":"Re: Allow git bisect to auto-skip","fromName":"Olliver Schinagl","fromEmail":"oliver@schinagl.nl","sentAt":"2024-03-23T20:51:28Z","receivedAt":"2024-03-23T20:51:31Z","isPatch":false,"sender":{"key":"oliver@schinagl.nl","avatar":"https://gravatar.com/avatar/abb8ef5f9b23563b7703a4114da6f9bd6e7f6d7e8e0296677547b20ff7740c56?d=mp&s=160"},"body":"On 23-03-2024 19:43, Junio C Hamano wrote:\n> Stefan Haller <lists@haller-berlin.de> writes:\n> \n>> On 22.03.24 23:31, Junio C Hamano wrote:\n>>> It often is discovered that a commit\n>>> breaks bisection after the fact and it is not feasible to rebase\n>>> all the history after the commit.\n>>\n>> This reminds me of a similar problem with git blame, for which we have\n>> the blame.ignoreRevsFile config to work around it. Couldn't there be a\n>> similar mechanism for bisect, e.g. bisect.skipRevsFile?\n> \n> A Very good point.  If a breakage of a commit is \"this does not even\n> build\" kind of breakage, such a mechanism would be an excellent fit.\n> \n> But if a breakage is \"only this particular test fails and we know\n> the reason why it fails has nothing to do with the bug we are\n> chasing\", then compiling such a fixed list of commits, or pointing\n> at such a list with a configuration variable, would not work very\n> well, I am afraid.\n\nThis changes my view of the issue a little bit. Building vs testing, \nthough in reality its the same of course.\n\nI can totally see that a user would need a special bisect script to \nhandle these cases 'this commit breaks test 54, 43 and 12; but the rest \nwork'. This is too specific to handle generically. Probably in using a \nsimilar trick, store in the notes what works and does not work.\n\nI think it still stands that having a 'generic' way of telling bisect to \nskip the entire commit is still reasonable. Kind of like how you can do \n`git push -o ci.skip=true` with GitLab.\n\nOlliver\n\n> \n> Thanks.\n"},{"id":"491341","messageId":"7610ff9c-b0d4-494c-a963-19494df2f74e@schinagl.nl","threadId":"61183","inReplyTo":"4cf100aa-4239-4377-b20a-7c90443fb405@schinagl.nl","subject":"Re: Allow git bisect to auto-skip","fromName":"Olliver Schinagl","fromEmail":"oliver@schinagl.nl","sentAt":"2024-03-24T07:47:01Z","receivedAt":"2024-03-24T07:47:09Z","isPatch":false,"sender":{"key":"oliver@schinagl.nl","avatar":"https://gravatar.com/avatar/abb8ef5f9b23563b7703a4114da6f9bd6e7f6d7e8e0296677547b20ff7740c56?d=mp&s=160"},"body":"On 23-03-2024 21:51, Olliver Schinagl wrote:\n> On 23-03-2024 19:43, Junio C Hamano wrote:\n>> Stefan Haller <lists@haller-berlin.de> writes:\n>>\n>>> On 22.03.24 23:31, Junio C Hamano wrote:\n>>>> It often is discovered that a commit\n>>>> breaks bisection after the fact and it is not feasible to rebase\n>>>> all the history after the commit.\n>>>\n>>> This reminds me of a similar problem with git blame, for which we have\n>>> the blame.ignoreRevsFile config to work around it. Couldn't there be a\n>>> similar mechanism for bisect, e.g. bisect.skipRevsFile?\n>>\n>> A Very good point.  If a breakage of a commit is \"this does not even\n>> build\" kind of breakage, such a mechanism would be an excellent fit.\n>>\n>> But if a breakage is \"only this particular test fails and we know\n>> the reason why it fails has nothing to do with the bug we are\n>> chasing\", then compiling such a fixed list of commits, or pointing\n>> at such a list with a configuration variable, would not work very\n>> well, I am afraid.\n> \n> This changes my view of the issue a little bit. Building vs testing, \n> though in reality its the same of course.\n> \n> I can totally see that a user would need a special bisect script to \n> handle these cases 'this commit breaks test 54, 43 and 12; but the rest \n> work'. This is too specific to handle generically. Probably in using a \n> similar trick, store in the notes what works and does not work.\n\nP.S. One (imo big) issue to me is, that notes aren't automatically \nfetched or pushed according to what I found so far online (haven't \npersonally tested it yet).\n\nIf that is the case, this makes the feature to be used in combination \nwith bisect much more difficult for the un-informed. having a \n`refs/notes/<bisect-or-like-related-name>` notes tree is great, but only \nif it gets automatically pulled.\n\nI think this also might be the reason it is a very undervalued thing maybe?\n\nOlliver\n\n> \n> I think it still stands that having a 'generic' way of telling bisect to \n> skip the entire commit is still reasonable. Kind of like how you can do \n> `git push -o ci.skip=true` with GitLab.\n> \n> Olliver\n> \n>>\n>> Thanks.\n"},{"id":"491346","messageId":"e896da79-c87b-4475-9890-10051d8ddf76@haller-berlin.de","threadId":"61183","inReplyTo":"xmqqle68x008.fsf@gitster.g","subject":"Re: Allow git bisect to auto-skip","fromName":"Stefan Haller","fromEmail":"lists@haller-berlin.de","sentAt":"2024-03-24T10:16:34Z","receivedAt":"2024-03-24T10:16:39Z","isPatch":false,"sender":{"key":"lists@haller-berlin.de","avatar":null},"body":"On 23.03.24 19:43, Junio C Hamano wrote:\n> Stefan Haller <lists@haller-berlin.de> writes:\n> \n>> On 22.03.24 23:31, Junio C Hamano wrote:\n>>> It often is discovered that a commit\n>>> breaks bisection after the fact and it is not feasible to rebase\n>>> all the history after the commit.\n>>\n>> This reminds me of a similar problem with git blame, for which we have\n>> the blame.ignoreRevsFile config to work around it. Couldn't there be a\n>> similar mechanism for bisect, e.g. bisect.skipRevsFile?\n> \n> A Very good point.  If a breakage of a commit is \"this does not even\n> build\" kind of breakage, such a mechanism would be an excellent fit.\n> \n> But if a breakage is \"only this particular test fails and we know\n> the reason why it fails has nothing to do with the bug we are\n> chasing\", then compiling such a fixed list of commits, or pointing\n> at such a list with a configuration variable, would not work very\n> well, I am afraid.\n\nThat's true, but the same can be said about blame.ignoreRevsFile. There\nmay be commits that contain both uninteresting whitespace changes and\nreal changes (not in a well-maintained project of course :-), so it\nwouldn't be a good idea to add those to blame.ignoreRevsFile. But that's\nnot a reason not to offer the feature at all.\n\n-Stefan\n"},{"id":"491351","messageId":"CAP8UFD2DhkmVias+RfMESJz9Z-rKKHWHB+MFHcDb9QLO16TOhg@mail.gmail.com","threadId":"61183","inReplyTo":"e896da79-c87b-4475-9890-10051d8ddf76@haller-berlin.de","subject":"Re: Allow git bisect to auto-skip","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-03-24T14:29:15Z","receivedAt":"2024-03-24T14:29:30Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sun, Mar 24, 2024 at 11:16 AM Stefan Haller <lists@haller-berlin.de> wrote:\n>\n> On 23.03.24 19:43, Junio C Hamano wrote:\n> > Stefan Haller <lists@haller-berlin.de> writes:\n> >\n> >> On 22.03.24 23:31, Junio C Hamano wrote:\n> >>> It often is discovered that a commit\n> >>> breaks bisection after the fact and it is not feasible to rebase\n> >>> all the history after the commit.\n> >>\n> >> This reminds me of a similar problem with git blame, for which we have\n> >> the blame.ignoreRevsFile config to work around it. Couldn't there be a\n> >> similar mechanism for bisect, e.g. bisect.skipRevsFile?\n> >\n> > A Very good point.  If a breakage of a commit is \"this does not even\n> > build\" kind of breakage, such a mechanism would be an excellent fit.\n> >\n> > But if a breakage is \"only this particular test fails and we know\n> > the reason why it fails has nothing to do with the bug we are\n> > chasing\", then compiling such a fixed list of commits, or pointing\n> > at such a list with a configuration variable, would not work very\n> > well, I am afraid.\n>\n> That's true, but the same can be said about blame.ignoreRevsFile. There\n> may be commits that contain both uninteresting whitespace changes and\n> real changes (not in a well-maintained project of course :-), so it\n> wouldn't be a good idea to add those to blame.ignoreRevsFile. But that's\n> not a reason not to offer the feature at all.\n\nI am not against the feature, but I think it would be especially\nuseful if the file(s) containing the revs that should be skipped\nis(are) tracked in Git. In this case though, any such file wouldn't be\nused automatically after cloning the repo as the bisect.skipRevsFile\noption would still need to be configured.\n\nAlso, how much better would this be compared to tracking  \"git bisect\nrun\" scripts in the repo, even if they have to be copied somewhere\nelse before they are launched? I wonder about this because writing the\nconditions that decide whether the current commit is good or bad might\nnot be so easy either. So if the goal is to simplify things for users,\nthen simplifying all the way by providing example scripts with\ncomments about how they could be customized might be even better.\n"},{"id":"491357","messageId":"066501da7e04$fecabf40$fc603dc0$@nexbridge.com","threadId":"61183","inReplyTo":"CAP8UFD2DhkmVias+RfMESJz9Z-rKKHWHB+MFHcDb9QLO16TOhg@mail.gmail.com","subject":"RE: Allow git bisect to auto-skip","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-03-24T16:04:41Z","receivedAt":"2024-03-24T16:05:10Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On Sunday, March 24, 2024 10:29 AM, Christian Couder wrote:\n>On Sun, Mar 24, 2024 at 11:16 AM Stefan Haller <lists@haller-berlin.de> wrote:\n>>\n>> On 23.03.24 19:43, Junio C Hamano wrote:\n>> > Stefan Haller <lists@haller-berlin.de> writes:\n>> >\n>> >> On 22.03.24 23:31, Junio C Hamano wrote:\n>> >>> It often is discovered that a commit breaks bisection after the\n>> >>> fact and it is not feasible to rebase all the history after the\n>> >>> commit.\n>> >>\n>> >> This reminds me of a similar problem with git blame, for which we\n>> >> have the blame.ignoreRevsFile config to work around it. Couldn't\n>> >> there be a similar mechanism for bisect, e.g. bisect.skipRevsFile?\n>> >\n>> > A Very good point.  If a breakage of a commit is \"this does not even\n>> > build\" kind of breakage, such a mechanism would be an excellent fit.\n>> >\n>> > But if a breakage is \"only this particular test fails and we know\n>> > the reason why it fails has nothing to do with the bug we are\n>> > chasing\", then compiling such a fixed list of commits, or pointing\n>> > at such a list with a configuration variable, would not work very\n>> > well, I am afraid.\n>>\n>> That's true, but the same can be said about blame.ignoreRevsFile.\n>> There may be commits that contain both uninteresting whitespace\n>> changes and real changes (not in a well-maintained project of course\n>> :-), so it wouldn't be a good idea to add those to\n>> blame.ignoreRevsFile. But that's not a reason not to offer the feature at all.\n>\n>I am not against the feature, but I think it would be especially useful if the file(s)\n>containing the revs that should be skipped\n>is(are) tracked in Git. In this case though, any such file wouldn't be used\n>automatically after cloning the repo as the bisect.skipRevsFile option would still\n>need to be configured.\n>\n>Also, how much better would this be compared to tracking  \"git bisect run\" scripts in\n>the repo, even if they have to be copied somewhere else before they are launched?\n>I wonder about this because writing the conditions that decide whether the current\n>commit is good or bad might not be so easy either. So if the goal is to simplify things\n>for users, then simplifying all the way by providing example scripts with comments\n>about how they could be customized might be even better.\n\nIn some situations, git bisect is used for compile issues, while others in debugging. In development branches, bisect is sufficient. However, if one has multiple production deploy branches, where feature merge squash happens multiple times into multiple branches, this makes finding the offending commit using bisect rather difficult as the defect may come in and out depending on the order in which feature branches are squashed (some may have the bug, while others don't). I can see the point of teaching bisect to knowingly skipping specific versions in this setting, although it is arguable that the investigation probably should not happen on the destination branches where functional stability cannot be guaranteed.\n\nBut this brought up a thought. What if bisect had the notion of parallel context: Meaning running two (or more) bisects in parallel on the same repo in search of two semi-independent defects, then analysing convergence between the two analyses - something like\n\n bisect 1: A(good) B(good) C(bad) D(bad);\n bisect 2: A(good) B(good) C(good) D(bad);\n bisect 3: A(good) B(bad) C(good) D(bad),   <- a production-like branch\n\nwith an interpretation that C and D may have interrelated defects but started showing in B in one situation. This is not a well-baked thought, but I can see this having some relevance when sub-modules are involved and bugs exist in more than one sub-module with bisects happening in the main repo. [note: I am not certain where I am going with this idea as of yet].\n\n--Randall\n\n"},{"id":"491373","messageId":"xmqq8r27sclp.fsf@gitster.g","threadId":"61183","inReplyTo":"CAP8UFD2DhkmVias+RfMESJz9Z-rKKHWHB+MFHcDb9QLO16TOhg@mail.gmail.com","subject":"Re: Allow git bisect to auto-skip","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-24T18:34:26Z","receivedAt":"2024-03-24T18:34:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder <christian.couder@gmail.com> writes:\n\n> Also, how much better would this be compared to tracking  \"git bisect\n> run\" scripts in the repo, even if they have to be copied somewhere\n> else before they are launched? I wonder about this because writing the\n> conditions that decide whether the current commit is good or bad might\n> not be so easy either. So if the goal is to simplify things for users,\n> then simplifying all the way by providing example scripts with\n> comments about how they could be customized might be even better.\n\nIf we are driving our bisection session via \"bisect run\" script,\ncomputing the condition that we need to skip in the script is the\nmost natural and obvious thing to do, but the way I guessed (because\nit was not explicitly written down) what the OP wanted was a way for\nbisect_next() called after even a manual \"git bisect (good|bad)\" to\nautomatically skip certain set of commits.  Because there are cases\nwhere you have to be testing manually and cannot afford to write\n\"bisect run\" script, giving a manual bisection a way to compute if a\ncommit need to be skipped may be worth having, and that was where my\n\"git bisect --skip-when <script>\" came from.  It would not be\nnecessary if you are doing \"bisect run\", which can dynamically tell\nif the commit is untestable.  And if the user is going to decide\nafter manually testing the one that is suggested, it is not useful\neither, as the point would be to avoid even asking to test ones that\nneed to be skipped.  So it is likely that the set of commits that\nneed skipping is known a-priori before the bisect session even\nbegins.  The end user experience may look like:\n\n * \"git bisect start\" takes \"--skip-when <script>\" and remembers it,\n   together with other options \"start\" can take (like <good>, <bad>,\n   <terms>, <pathspec>).\n\n - If <good> and <bad> are already given upon \"start\", the command\n   may check out a revision and ask you to test.\n\n * Every time the command checks out a revision to be tested by the\n   user, the command guarantees if it satisfies the --skip-when\n   condition (and internally doing \"git bisect skip\").\n\n * Otherwise the interaction between the user and the session is\n   exactly the same as usual.\n\n"},{"id":"491707","messageId":"7556a3de-a6a6-4284-8c36-3635ae43c653@schinagl.nl","threadId":"61183","inReplyTo":"xmqq8r27sclp.fsf@gitster.g","subject":"Re: Allow git bisect to auto-skip","fromName":"Olliver Schinagl","fromEmail":"oliver@schinagl.nl","sentAt":"2024-03-27T18:33:03Z","receivedAt":"2024-03-27T18:33:07Z","isPatch":false,"sender":{"key":"oliver@schinagl.nl","avatar":"https://gravatar.com/avatar/abb8ef5f9b23563b7703a4114da6f9bd6e7f6d7e8e0296677547b20ff7740c56?d=mp&s=160"},"body":"On 24-03-2024 19:34, Junio C Hamano wrote:\n> Christian Couder <christian.couder@gmail.com> writes:\n> \n>> Also, how much better would this be compared to tracking  \"git bisect\n>> run\" scripts in the repo, even if they have to be copied somewhere\n>> else before they are launched? I wonder about this because writing the\n>> conditions that decide whether the current commit is good or bad might\n>> not be so easy either. So if the goal is to simplify things for users,\n>> then simplifying all the way by providing example scripts with\n>> comments about how they could be customized might be even better.\n> \n> If we are driving our bisection session via \"bisect run\" script,\n> computing the condition that we need to skip in the script is the\n> most natural and obvious thing to do, but the way I guessed (because\n> it was not explicitly written down) what the OP wanted was a way for\n> bisect_next() called after even a manual \"git bisect (good|bad)\" to\n> automatically skip certain set of commits.\n\nI think you understood what I failed to properly explain :)\n\nTo come up with an RFC, I was trying to study the git code, and while \nsome things are quite readable, others are a bit complex.\n\nAfter some poking, I was thinking of using `find_bisection()`, or rather \n`do_find_bisection()` but got lost there.\n\nWhat made sense initially was, that in `find_bisection()` there is a \nsimple for loop that goes over the list of commits to count them. But \nwriting this down, I realize the list of commits is already there in \n`struct commit_list *list`, so I should probably go find out where the \nlist is being created!\n\nAnyway, want I was thinking of, based a key somewhere in the message \nbody (GIT_BISECT_SKIP=1 for example), mark the commit in the list to be \nskipped, as `git bisect skip` would. This so the skipped commit actualyl \nends up on the list of skipped commits (`refs/bisect/skip-*`).\n\nBut being a bit lost, it would be nice to get some directional pointers.\n\nIs this even possible? What is the easiest way to get the message from \nthe `struct commit_list *list` item, are there helpers to parse the \nmessage at all?\n\nThanks,\nOlliver\n\n>  Because there are cases\n> where you have to be testing manually and cannot afford to write\n> \"bisect run\" script, giving a manual bisection a way to compute if a\n> commit need to be skipped may be worth having, and that was where my\n> \"git bisect --skip-when <script>\" came from.  It would not be\n> necessary if you are doing \"bisect run\", which can dynamically tell\n> if the commit is untestable.  And if the user is going to decide\n> after manually testing the one that is suggested, it is not useful\n> either, as the point would be to avoid even asking to test ones that\n> need to be skipped.  So it is likely that the set of commits that\n> need skipping is known a-priori before the bisect session even\n> begins.  The end user experience may look like:\n> \n>   * \"git bisect start\" takes \"--skip-when <script>\" and remembers it,\n>     together with other options \"start\" can take (like <good>, <bad>,\n>     <terms>, <pathspec>).\n> \n>   - If <good> and <bad> are already given upon \"start\", the command\n>     may check out a revision and ask you to test.\n> \n>   * Every time the command checks out a revision to be tested by the\n>     user, the command guarantees if it satisfies the --skip-when\n>     condition (and internally doing \"git bisect skip\").\n> \n>   * Otherwise the interaction between the user and the session is\n>     exactly the same as usual.\n> \n"},{"id":"491708","messageId":"xmqqfrwb1nr8.fsf@gitster.g","threadId":"61183","inReplyTo":"7556a3de-a6a6-4284-8c36-3635ae43c653@schinagl.nl","subject":"Re: Allow git bisect to auto-skip","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-27T19:24:43Z","receivedAt":"2024-03-27T19:24:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Olliver Schinagl <oliver@schinagl.nl> writes:\n\n> Anyway, want I was thinking of, based a key somewhere in the message\n> body (GIT_BISECT_SKIP=1 for example), mark the commit in the list to\n> be skipped, as `git bisect skip` would. This so the skipped commit\n> actualyl ends up on the list of skipped commits\n> (`refs/bisect/skip-*`).\n\nI think it is very unlikely that we'd adopt any hardcoded scheme\nthat allows only one supported way of marking commits as not to be\ntested.  Certainly not the kind that the committer is forced to know\nthe commit must be skipped during a bisection session before\ncreating the commit.  So I am not sure how much good it will do to\nknow that commit_list->item is a commit object on the list, or\ncalling repo_get_commit_buffer() on it would give the contents of\nthe commit object.\n\nKnowing that commit_list->item->object.oid is the object name of\nsuch a commit, and calling oid_to_hex() on such an object name\nstringifies it, should be sufficient to write a new code that calls\nout to a script specified via \"git bisect --skip-when=<script>\"\nusing the run_command() API to decide if the commit object should be\nskipped, and if you do want GIT_BISECT_SKIP=1 in the log message,\nyour script given via --skip-when may be a single-liner:\n\n    #!/bin/sh\n    # usage: this-script $commit_object_name\n    # expected to exit with 0 when the commit should not be tested\n    git cat-file commit \"$1\" | sed -e '1,/^$/d' | grep GIT_BISECT_SKIP=1\n\nThanks.\n"},{"id":"491726","messageId":"e94be8ec-87aa-4703-b6bf-b37dd4919752@schinagl.nl","threadId":"61183","inReplyTo":"xmqqfrwb1nr8.fsf@gitster.g","subject":"Re: Allow git bisect to auto-skip","fromName":"Olliver Schinagl","fromEmail":"oliver@schinagl.nl","sentAt":"2024-03-28T08:01:03Z","receivedAt":"2024-03-28T08:01:06Z","isPatch":false,"sender":{"key":"oliver@schinagl.nl","avatar":"https://gravatar.com/avatar/abb8ef5f9b23563b7703a4114da6f9bd6e7f6d7e8e0296677547b20ff7740c56?d=mp&s=160"},"body":"On 27-03-2024 20:24, Junio C Hamano wrote:\n> Olliver Schinagl <oliver@schinagl.nl> writes:\n>\n>> Anyway, want I was thinking of, based a key somewhere in the message\n>> body (GIT_BISECT_SKIP=1 for example), mark the commit in the list to\n>> be skipped, as `git bisect skip` would. This so the skipped commit\n>> actualyl ends up on the list of skipped commits\n>> (`refs/bisect/skip-*`).\n> I think it is very unlikely that we'd adopt any hardcoded scheme\n> that allows only one supported way of marking commits as not to be\n> tested.  Certainly not the kind that the committer is forced to know\n> the commit must be skipped during a bisection session before\n> creating the commit.\n\nMy goal is to make things work as automagically as possible, without \nspecial tooling or scripts. This to make the barrier for entry as low as \npossible. E.g. if someone says 'could you please bisect this for me', \nthings should just work.\n\nHaving said that, I also realize that the use-cases where a commit \nmessage would be enough are limited. There's only a very rare cases \nwhere it is known before hand a commit will break bisect.\n\nThe `GIT_BISECT_SKIP=1` would obviously be configurable, so it could be \nset on a per-repo level, with a sane default, and probably wiser to use \n`git commit --skip-bisect` to make use of said flag.\n\n\nHaving said all that, right now, I'm just exploring how things work, how \neasy it would be, how logical it would be. So for thank you for bearing \nwith me :)\n\n>    So I am not sure how much good it will do to\n> know that commit_list->item is a commit object on the list, or\n> calling repo_get_commit_buffer() on it would give the contents of\n> the commit object.\n>\n> Knowing that commit_list->item->object.oid is the object name of\n> such a commit, and calling oid_to_hex() on such an object name\n> stringifies it, should be sufficient to write a new code that calls\n> out to a script specified via \"git bisect --skip-when=<script>\"\n\nI had learned about `oid_to_hex()` already, and I am charmed by that \nidea for sure. So much in that I'll look into this first. In the end, \nboth solutions could even be used as they are in nearly the same spot \nI'd think.\n\n\nFour things I lack right now. The first one I hope to have figured out \nbefore your reply (but don't shy the reply).\n\n1) What is the best way to parse the skip-when argument. I see \n`bisect_start()` does arg parsing, but trying to see what 'the git way' \nis to get the argument of the new flag.\n\n2) Where to store the argument. `bisect_terms` is passed around \neverywhere to hold the good and bad states, but with bisect doesn't pass \nmuch of anything else around. Though `bisect_run` isn't storing \n`command` either, and you do mention so I'll delve into that and see how \nthat maps into the `run_command()` API.\n\n3) Using the `run_command()` API implies to do the check 'on checkout'; \nwhich was my first idea as well, but a) where does this happen? I have \nnot found this yet, though `bisect_run` might be more revealing here,\n\n3) Using this approach, can I still do a 'regular' `git bisect skip` in \nthat the skip gets recorded (in refs/bisect/skip-*)? I think it would be \nnice to see what was skipped.\n\n\nThanks,\n\nOlliver\n\n> using the run_command() API to decide if the commit object should be\n> skipped, and if you do want GIT_BISECT_SKIP=1 in the log message,\n> your script given via --skip-when may be a single-liner:\n>\n>      #!/bin/sh\n>      # usage: this-script $commit_object_name\n>      # expected to exit with 0 when the commit should not be tested\n>      git cat-file commit \"$1\" | sed -e '1,/^$/d' | grep GIT_BISECT_SKIP=1\n>\n> Thanks.\n\n\n"}]}