On 2022-11-02 05:47, Gregory Heytings wrote:
> Eglot's merge (0186faf2a1) is the first case in Emacs' history in
> which another root commit (1e5b753bf4) was added to the repository.
> So at the moment there is only one such command to type when starting
> a bisection: git bisect good 806734c1b1.
> 
> Eli, what do you think of adding an admin/git-bisect script to do
> that? In the future, if other similar merges are done, it would
> suffice to add another such line in that file.

As another opt-in alternative, the git bisect commands for starting
and iterating on a bisection run a "git checkout" and so we can use
the post-checkout git hook to automate this.  I'm not aware of any
better choice[1] of hook here, so we need it to first ascertain that
the checkout is even involved in a git bisect, but I've attached a
proof of concept which works for me.  It's a bit fiddly in that it
means the "git bisect good <ref>" runs before the triggering "git
bisect start" command has finished (as can be observed in the output),
but this appears to be ok in practice.  The hook also has no idea
when the bisect has been completed, as all the BISECT* files are
still present when "git bisect reset" does its checkout; but because
the hook adds to the bisect log, it can detect whether or not a NEW
bisect has started, which is the important thing.

Client-side git hooks must be installed manually by the user (they
cannot be supplied automatically while cloning), so it would be up to
individuals to follow some documentation to do this; but the benefit
of a hook-based approach is that it should work regardless of how the
"git bisect start" is triggered (rather than relying on people using
the command line), which benefits people using Magit's bisect UI (to
pick an obvious example).

If we provide something like this, I suggest we also comment the file
of known-good commits with all the details of each entry, and just
grep out the comment lines when processing it.


-Phil

[1]: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks