all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Phil Sainty <psainty@orcon.net.nz>
To: Gregory Heytings <gregory@heytings.org>
Cc: "Michael Albinus" <michael.albinus@gmx.de>,
	"Gerd Möllmann" <gerd.moellmann@gmail.com>,
	emacs-devel@gnu.org
Subject: Re: Emacs git repo mangled
Date: Wed, 02 Nov 2022 15:11:06 +1300	[thread overview]
Message-ID: <7be379b823dbdfe02ddf29c023b73d88@webmail.orcon.net.nz> (raw)
In-Reply-To: <48c054670f81f5613f23@heytings.org>

[-- Attachment #1: Type: text/plain, Size: 2043 bytes --]

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: post-checkout --]
[-- Type: text/x-shellscript; name=post-checkout, Size: 2073 bytes --]

#!/bin/sh

## General information on Git post-checkout hooks:
#
# This hook is invoked when a git checkout is run after having updated
# the worktree. The hook is given three parameters: the ref of the
# previous HEAD, the ref of the new HEAD (which may or may not have
# changed), and a flag indicating whether the checkout was a branch
# checkout (changing branches, flag=1) or a file checkout (retrieving
# a file from the index, flag=0). This hook cannot affect the outcome
# of git checkout.
#
# It is also run after git clone, unless the --no-checkout (-n) option
# is used. The first parameter given to the hook is the null-ref, the
# second the ref of the new HEAD and the flag is always 1.
#
# This hook can be used to perform repository validity checks,
# auto-display differences from the previous HEAD if different, or set
# working dir metadata properties.

head_old=$1
head_new=$2
flag=$3

# We are interested only in branch checkouts.
if [ "$flag" != "1" ]; then
    exit 0
fi

# n.b. pwd will be this working copy's root directory.
root=$(pwd)

# printf "$0: %s - %s - %s\n" "$@"
# ls -l "$root"/.git/BISECT*

if [ -f "$root/.git/BISECT_LOG" ]; then
    # Currently bisecting.  If the ONLY thing which has happened so
    # far is the "git bisect start" command, then mark our always-good
    # commits as "good".  (This will append to the log, after which
    # the following test will fail.)
    tail -1 "$root/.git/BISECT_LOG" | grep -q '^git bisect .*\bstart\b' \
        && [ -f "$root/etc/git-bisect-good-refs" ] \
        && cp "$root/etc/git-bisect-good-refs" "$root/.git/BISECT_EMACS_GOOD_REFS" \
        && printf %s\\n "Marking known-good references in Emacs repository." \
        && cat "$root/.git/BISECT_EMACS_GOOD_REFS" | xargs git bisect good \
        && git bisect log
else
    # Not currently bisecting; just tidy up.
    [ -f "$root/.git/BISECT_EMACS_GOOD_REFS" ] \
        && rm "$root/.git/BISECT_EMACS_GOOD_REFS"
fi

exit 0

# etc/git-bisect-good-refs is a file containing this commit ref:
# 806734c1b1f433de43d59d9a5e3a1e89d64315f6

  parent reply	other threads:[~2022-11-02  2:11 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-31  9:50 Emacs git repo mangled Michael Albinus
2022-10-31 13:09 ` Gerd Möllmann
2022-10-31 16:43   ` Michael Albinus
2022-11-01  5:44     ` Gerd Möllmann
2022-11-01  9:15       ` Michael Albinus
2022-11-01  9:28         ` Gerd Möllmann
2022-11-01 12:07         ` Gregory Heytings
2022-11-01 13:32           ` Michael Albinus
2022-11-01 13:55             ` Gregory Heytings
2022-11-01 15:23               ` Michael Albinus
2022-11-01 16:47                 ` Gregory Heytings
2022-11-01 17:19                   ` Eli Zaretskii
2022-11-01 18:25                     ` Gregory Heytings
2022-11-02  5:51                       ` Gerd Möllmann
2022-11-02  9:26                         ` Gregory Heytings
2022-11-01 19:02                   ` Michael Albinus
2022-11-01 19:41                     ` Gregory Heytings
2022-11-02  3:26                       ` Eli Zaretskii
2022-11-02  9:14                         ` Gregory Heytings
2022-11-02 12:59                           ` Phil Sainty
2022-11-02 13:10                             ` Gregory Heytings
2022-11-02 13:49                           ` Eli Zaretskii
2022-11-02 14:27                             ` Gregory Heytings
2022-11-05 10:54                       ` Michael Albinus
2022-11-05 21:58                         ` Gregory Heytings
2022-11-02  2:11                   ` Phil Sainty [this message]
2022-11-02 10:56                     ` Robert Pluim
2022-10-31 13:38 ` Andreas Schwab
2022-10-31 16:45   ` Michael Albinus
2022-10-31 15:35 ` João Távora
2022-10-31 16:04   ` Stefan Kangas
2022-10-31 16:24     ` João Távora
2022-10-31 17:28       ` Stefan Kangas
2022-10-31 21:45 ` Gregory Heytings
  -- strict thread matches above, loose matches on Subject: below --
2022-10-31 15:25 Payas Relekar
2022-10-31 16:11 ` João Távora
2022-10-31 16:48   ` Michael Albinus
2022-10-31 17:57   ` Stefan Monnier
2022-10-31 18:33     ` Andreas Schwab
2022-10-31 20:39       ` Stefan Monnier
2022-10-31 21:10         ` Óscar Fuentes
2022-10-31 21:15         ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7be379b823dbdfe02ddf29c023b73d88@webmail.orcon.net.nz \
    --to=psainty@orcon.net.nz \
    --cc=emacs-devel@gnu.org \
    --cc=gerd.moellmann@gmail.com \
    --cc=gregory@heytings.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.