[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs git repo mangled

From: Phil Sainty
Subject: Re: Emacs git repo mangled
Date: Wed, 02 Nov 2022 15:11:06 +1300
User-agent: Orcon Webmail

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.


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

Attachment: post-checkout
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]