{"thread":{"id":"66455","subject":"git-visualize(1) plumbing equivalent","startedAt":"2026-10-03T10:10:51Z","lastAt":"2026-10-03T17:50:33Z","messageCount":7,"participants":["Alejandro Colomar","D. Ben Knoble","Kristoffer Haugsbakk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"554051","messageId":"asDTWsH-RuIJOyne@debian","threadId":"66455","inReplyTo":null,"subject":"git-visualize(1) plumbing equivalent","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2026-10-03T10:10:44Z","receivedAt":"2026-10-03T10:10:51Z","isPatch":false,"body":"Hi!\n\nI have this code, which I use to loop in a script using git-bisect(1):\n\n\twhile\n\t\tgit bisect visualize --oneline \\\n\t\t| wc -l \\\n\t\t| xargs -I{} test {} -gt 1;\n\tdo\n\t\tif\n\t\t\tgit rebase $gropts BISECT_HEAD >/dev/null 2>/dev/null;\n\t\t\ttest $? -eq 0;\n\t\tthen\n\t\t\techo 'Rebase: success';\n\t\t\tgit bisect good BISECT_HEAD;\n\t\telse\n\t\t\techo 'Rebase: conflict';\n\t\t\tgit rebase --abort >/dev/null;\n\t\t\tgit bisect bad BISECT_HEAD;\n\t\tfi;\n\tdone;\n\n(\nI know this resembles \"git rebase run\", but I'm avoiding it, because\npassing all of that as a command is non-trivial (and I'd like to avoid\nhaving to write a separate script to pass its name to \"git bisect run\").\n)\n\nHaving read the documentation for git-bisect(1), visualize reads several\nenvironment variables, and thus this code doesn't seem robust.  What\nwould be the plumbing version of the while-loop condition?\n\n\t\tgit bisect visualize --oneline \\\n\t\t| wc -l \\\n\t\t| xargs -I{} test {} -gt 1;\n\nThe goal is to know whether git-bisect(1) has found a commit yet or not,\nto stop looping.\n\n\nHave a lovely day!\nAlex\n\n-- \n<https://www.alejandro-colomar.es>\n"},{"id":"554064","messageId":"CALnO6CCUY2KF8rEotihdVNy+D10mmzuW0RXbH8nqhSS9jsgQUg@mail.gmail.com","threadId":"66455","inReplyTo":"asDTWsH-RuIJOyne@debian","subject":"Re: git-visualize(1) plumbing equivalent","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-10-03T13:45:17Z","receivedAt":"2026-10-03T13:45:30Z","isPatch":false,"body":"On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:\n>\n> Hi!\n>\n> I have this code, which I use to loop in a script using git-bisect(1):\n>\n>         while\n>                 git bisect visualize --oneline \\\n>                 | wc -l \\\n>                 | xargs -I{} test {} -gt 1;\n>         do\n>                 if\n>                         git rebase $gropts BISECT_HEAD >/dev/null 2>/dev/null;\n>                         test $? -eq 0;\n\nAside: this \"test $? -eq 0\" is a bit redundant, no? \"if cmd\" in shell\nworks by checking whether \"cmd\" exits 0 or not.\n\n>                 then\n>                         echo 'Rebase: success';\n>                         git bisect good BISECT_HEAD;\n>                 else\n>                         echo 'Rebase: conflict';\n>                         git rebase --abort >/dev/null;\n>                         git bisect bad BISECT_HEAD;\n>                 fi;\n>         done;\n>\n> (\n> I know this resembles \"git rebase run\", but I'm avoiding it, because\n> passing all of that as a command is non-trivial (and I'd like to avoid\n> having to write a separate script to pass its name to \"git bisect run\").\n> )\n>\n> Having read the documentation for git-bisect(1), visualize reads several\n> environment variables, and thus this code doesn't seem robust.  What\n> would be the plumbing version of the while-loop condition?\n>\n>                 git bisect visualize --oneline \\\n>                 | wc -l \\\n>                 | xargs -I{} test {} -gt 1;\n>\n> The goal is to know whether git-bisect(1) has found a commit yet or not,\n> to stop looping.\n\nI think you are probably looking for the (size of the) set of commits\nbetween bisect/bad and all the bisect/good-* refs. So you might need\nto \"git refs list\" the good ones, and feed those as negated refs\nalongside bisect/bad to rev-list?\n\nIn the general case, that wouldn't account for skipped commits as I\nunderstand it, where multiple commits are left at the end of the\nbisect, but in your script it doesn't look like you skip any.\n\n-- \nD. Ben Knoble\n"},{"id":"554067","messageId":"asEa_Lp01DVJ2ThZ@debian","threadId":"66455","inReplyTo":"CALnO6CCUY2KF8rEotihdVNy+D10mmzuW0RXbH8nqhSS9jsgQUg@mail.gmail.com","subject":"Re: git-visualize(1) plumbing equivalent","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2026-10-03T15:13:26Z","receivedAt":"2026-10-03T15:13:31Z","isPatch":false,"body":"Hi Ben,\n\n> Date: 2026-10-03 09:45:17-0400\n> From: \"D. Ben Knoble\" <ben.knoble@gmail.com>\n>\n> On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:\n> >\n> > Hi!\n> >\n> > I have this code, which I use to loop in a script using git-bisect(1):\n> >\n> >         while\n> >                 git bisect visualize --oneline \\\n> >                 | wc -l \\\n> >                 | xargs -I{} test {} -gt 1;\n> >         do\n> >                 if\n> >                         git rebase $gropts BISECT_HEAD >/dev/null 2>/dev/null;\n> >                         test $? -eq 0;\n> \n> Aside: this \"test $? -eq 0\" is a bit redundant, no? \"if cmd\" in shell\n> works by checking whether \"cmd\" exits 0 or not.\n\nOuch!  Indeed.  IIRC, I originally had the test reversed (-ne 0), and\nlater probably flipped without thinking it could be removed.  :)\n\n> \n> >                 then\n> >                         echo 'Rebase: success';\n> >                         git bisect good BISECT_HEAD;\n> >                 else\n> >                         echo 'Rebase: conflict';\n> >                         git rebase --abort >/dev/null;\n> >                         git bisect bad BISECT_HEAD;\n> >                 fi;\n> >         done;\n> >\n> > (\n> > I know this resembles \"git rebase run\", but I'm avoiding it, because\n> > passing all of that as a command is non-trivial (and I'd like to avoid\n> > having to write a separate script to pass its name to \"git bisect run\").\n> > )\n> >\n> > Having read the documentation for git-bisect(1), visualize reads several\n> > environment variables, and thus this code doesn't seem robust.  What\n> > would be the plumbing version of the while-loop condition?\n> >\n> >                 git bisect visualize --oneline \\\n> >                 | wc -l \\\n> >                 | xargs -I{} test {} -gt 1;\n> >\n> > The goal is to know whether git-bisect(1) has found a commit yet or not,\n> > to stop looping.\n> \n> I think you are probably looking for the (size of the) set of commits\n> between bisect/bad and all the bisect/good-* refs. So you might need\n> to \"git refs list\" the good ones, and feed those as negated refs\n> alongside bisect/bad to rev-list?\n\nYup, this seems to work:\n\ngit refs list | grep refs/bisect/ | sed '/good/s/^/^/' | cut -f1 -d' ' | xargs git rev-list \n\n> \n> In the general case, that wouldn't account for skipped commits as I\n> understand it, where multiple commits are left at the end of the\n> bisect, but in your script it doesn't look like you skip any.\n\nHmmmm.  I'm now working on adding the ability to skip commits, so this\nwould be a problem.  Do you have any idea on how to deal with that?\n\n\nHave a lovely day!\nAlex\n\n> \n> -- \n> D. Ben Knoble\n\n-- \n<https://www.alejandro-colomar.es>\n"},{"id":"554068","messageId":"37597cc9-0cfe-4a1b-8c7e-1d229c9f7cf0@app.fastmail.com","threadId":"66455","inReplyTo":"CALnO6CCUY2KF8rEotihdVNy+D10mmzuW0RXbH8nqhSS9jsgQUg@mail.gmail.com","subject":"Re: git-visualize(1) plumbing equivalent","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2026-10-03T15:26:36Z","receivedAt":"2026-10-03T15:27:10Z","isPatch":false,"body":"On Sat, Oct 3, 2026, at 15:45, D. Ben Knoble wrote:\n>[snip]\n> On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:\n>>[snip]\n>> The goal is to know whether git-bisect(1) has found a commit yet or not,\n>> to stop looping.\n>\n> I think you are probably looking for the (size of the) set of commits\n> between bisect/bad and all the bisect/good-* refs. So you might need\n> to \"git refs list\" the good ones, and feed those as negated refs\n> alongside bisect/bad to rev-list?\n\nI think you can do that directly with `git rev-list --bisect` and the\nother variants that start with `--bisect-`.\n\nI have never used them myself.\n\n>\n> In the general case, that wouldn't account for skipped commits as I\n> understand it, where multiple commits are left at the end of the\n> bisect, but in your script it doesn't look like you skip any.\n"},{"id":"554070","messageId":"CALnO6CATXadzAfvwEpG7po5dH+scd6KxGxRqXvw6w+zN5krreQ@mail.gmail.com","threadId":"66455","inReplyTo":"37597cc9-0cfe-4a1b-8c7e-1d229c9f7cf0@app.fastmail.com","subject":"Re: git-visualize(1) plumbing equivalent","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-10-03T17:09:39Z","receivedAt":"2026-10-03T17:09:51Z","isPatch":false,"body":"On Sat, Oct 3, 2026 at 11:27 AM Kristoffer Haugsbakk\n<kristofferhaugsbakk@fastmail.com> wrote:\n>\n> On Sat, Oct 3, 2026, at 15:45, D. Ben Knoble wrote:\n> >[snip]\n> > On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:\n> >>[snip]\n> >> The goal is to know whether git-bisect(1) has found a commit yet or not,\n> >> to stop looping.\n> >\n> > I think you are probably looking for the (size of the) set of commits\n> > between bisect/bad and all the bisect/good-* refs. So you might need\n> > to \"git refs list\" the good ones, and feed those as negated refs\n> > alongside bisect/bad to rev-list?\n>\n> I think you can do that directly with `git rev-list --bisect` and the\n> other variants that start with `--bisect-`.\n>\n> I have never used them myself.\n\nThanks, TIL.\n\n-- \nD. Ben Knoble\n"},{"id":"554071","messageId":"CALnO6CAsd36-XEnRQWNhAsmH7Bg6ZoHv7qb2xQ1m0cW4-Decmw@mail.gmail.com","threadId":"66455","inReplyTo":"asEa_Lp01DVJ2ThZ@debian","subject":"Re: git-visualize(1) plumbing equivalent","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2026-10-03T17:10:43Z","receivedAt":"2026-10-03T17:10:55Z","isPatch":false,"body":"On Sat, Oct 3, 2026 at 11:13 AM Alejandro Colomar <alx@kernel.org> wrote:\n>\n> Hi Ben,\n>\n> > Date: 2026-10-03 09:45:17-0400\n> > From: \"D. Ben Knoble\" <ben.knoble@gmail.com>\n> >\n> > On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:\n\n[snip]\n\n> > > Having read the documentation for git-bisect(1), visualize reads several\n> > > environment variables, and thus this code doesn't seem robust.  What\n> > > would be the plumbing version of the while-loop condition?\n> > >\n> > >                 git bisect visualize --oneline \\\n> > >                 | wc -l \\\n> > >                 | xargs -I{} test {} -gt 1;\n> > >\n> > > The goal is to know whether git-bisect(1) has found a commit yet or not,\n> > > to stop looping.\n> >\n> > I think you are probably looking for the (size of the) set of commits\n> > between bisect/bad and all the bisect/good-* refs. So you might need\n> > to \"git refs list\" the good ones, and feed those as negated refs\n> > alongside bisect/bad to rev-list?\n>\n> Yup, this seems to work:\n>\n> git refs list | grep refs/bisect/ | sed '/good/s/^/^/' | cut -f1 -d' ' | xargs git rev-list\n>\n> >\n> > In the general case, that wouldn't account for skipped commits as I\n> > understand it, where multiple commits are left at the end of the\n> > bisect, but in your script it doesn't look like you skip any.\n>\n> Hmmmm.  I'm now working on adding the ability to skip commits, so this\n> would be a problem.  Do you have any idea on how to deal with that?\n\nNot offhand, sorry :/ I'm not totally sure how bisect represents that state.\n\n-- \nD. Ben Knoble\n"},{"id":"554072","messageId":"asFAEwomFDbC2Dec@debian","threadId":"66455","inReplyTo":"CALnO6CAsd36-XEnRQWNhAsmH7Bg6ZoHv7qb2xQ1m0cW4-Decmw@mail.gmail.com","subject":"Re: git-visualize(1) plumbing equivalent","fromName":"Alejandro Colomar","fromEmail":"alx@kernel.org","sentAt":"2026-10-03T17:50:28Z","receivedAt":"2026-10-03T17:50:33Z","isPatch":false,"body":"Hi Ben,\n\n> Date: 2026-10-03 13:10:43-0400\n> From: \"D. Ben Knoble\" <ben.knoble@gmail.com>\n>\n> On Sat, Oct 3, 2026 at 11:13 AM Alejandro Colomar <alx@kernel.org> wrote:\n> >\n> > Hi Ben,\n> >\n> > > Date: 2026-10-03 09:45:17-0400\n> > > From: \"D. Ben Knoble\" <ben.knoble@gmail.com>\n> > >\n> > > On Sat, Oct 3, 2026 at 6:13 AM Alejandro Colomar <alx@kernel.org> wrote:\n> \n> [snip]\n> \n> > > > Having read the documentation for git-bisect(1), visualize reads several\n> > > > environment variables, and thus this code doesn't seem robust.  What\n> > > > would be the plumbing version of the while-loop condition?\n> > > >\n> > > >                 git bisect visualize --oneline \\\n> > > >                 | wc -l \\\n> > > >                 | xargs -I{} test {} -gt 1;\n> > > >\n> > > > The goal is to know whether git-bisect(1) has found a commit yet or not,\n> > > > to stop looping.\n> > >\n> > > I think you are probably looking for the (size of the) set of commits\n> > > between bisect/bad and all the bisect/good-* refs. So you might need\n> > > to \"git refs list\" the good ones, and feed those as negated refs\n> > > alongside bisect/bad to rev-list?\n> >\n> > Yup, this seems to work:\n> >\n> > git refs list | grep refs/bisect/ | sed '/good/s/^/^/' | cut -f1 -d' ' | xargs git rev-list\n> >\n> > >\n> > > In the general case, that wouldn't account for skipped commits as I\n> > > understand it, where multiple commits are left at the end of the\n> > > bisect, but in your script it doesn't look like you skip any.\n> >\n> > Hmmmm.  I'm now working on adding the ability to skip commits, so this\n> > would be a problem.  Do you have any idea on how to deal with that?\n> \n> Not offhand, sorry :/ I'm not totally sure how bisect represents that state.\n\nThanks anyway!  I think this is getting hard enough, that it might be\nworth piping a heredocument into a mktemp(1) file within the script, and\npassing that to 'git bisect run'.\n\n\nCheers,\nAlex\n\n-- \n<https://www.alejandro-colomar.es>\n"}]}