Re: [PATCH v4] hooks: propose project configured hooks

From: Jonathan Tan <jonathantanmy@google.com>
Date: Jun 3, 2021, 03:31 UTC
Message-ID: <20210603033142.353066-1-jonathantanmy@google.com>
In-Reply-To: <pull.908.v4.git.1620241892929.gitgitgadget@gmail.com>

Show 7 quoted lines

> +* After clone, repository suggests hooks to the user
> +
> +    ** User receives a non-interactive message advertising hooks available to
> +    install
> +
> +    ** User can see what hooks and commands are being suggested and from what
> +    remote.

From the implementation point of view, would it be sufficient to just advertise that hooks are available? Assuming that the hooks will be available from a specially named ref (as stated below), then we would only need to inform the user that this ref exists and hooks can be inspected using a special command. Likewise for when we fetch and notice that the ref now points to a different object. Then, we wouldn't need to do any extra fetching upon clone/fetch, saving time and bandwidth, but just do so if the user requests it.

Show 5 quoted lines

> +Feature Requirements
> +~~~~~~~~~~~~~~~~~~~~
> +
> +Minimum Feature Set
> +^^^^^^^^^^^^^^^^^^^

[snip]

Show 9 quoted lines

> +* The configuration specifies where the hook commands reside
> +
> +    ** This could be a path to a script/binary within the repository
> +
> +    ** This could be a path to a script/binary contained within submodules of
> +    the repository
> +
> +    ** This could be a user installed command or script/binary that exists
> +    outside of the repository and is present in `$PATH`

Right now hooks are fixed files (well, not counting Emily Shaffer's work on config hooks). Would it be sufficient to just provide replacements for those files?

Show 8 quoted lines

> +* The configuration lives outside the worktree.
> +
> +    ** Allows updated hooks to apply across history and branches, reducing
> +    the maintenance burden of keeping hooks updated.
> +
> +    ** Allows different remotes to specify different configuration. This is
> +    useful for public vs private central repositories or for repositories which
> +    support different Git functionality.

Hmm...what would be a use case of this? And how would, say, a pre-commit hook know which remote it is for?

Show 16 quoted lines

> +* The user receives advice to install hooks.
> +
> +    ** The advice should clearly indicate the suggested hook command(s) and hook
> +    event(s) as well as the central repository that is suggesting them (via
> +    remote URL).
> +
> +    ** The user should be able to use configuration to turn off this advice.
> +
> +    ** The advice should appear at the following times:
> +
> +        *** After a clone
> +
> +        *** After a suggested hook would have run if not already installed. The
> +        advice should include commands for installing the hook and invoking it.
> +        For example, for a hook on 'git commit', the user should receive advice
> +        to amend their commit after hook installation.

This seems contradictory to a point above where we only inform the user upon clone (when the user is in the setup mood).

> +* If, after fetch, the central repository suggests new or updated hooks, the
> +user should receive advice to install these new hooks (note: implementation
> +should not interfere with requirement listed in“Fast Follows")

In Git, the term "advice" seems to be used more for extra explanations that you can turn off once you're experienced with Git. Here, these seem like things that we would want to notify users about regardless of experience level, so maybe the word "notification" is more appropriate.

Show 11 quoted lines

> +* Works across Windows/Linux/macOS
> +
> +Fast Follows
> +^^^^^^^^^^^^
> +
> +* Behind configuration, a user can opt to automatically install hook updates
> +from a given remote.
> +
> +* Allow users to make trust decisions based on GPG signing e.g. if the
> +configuration came from a signed commit, the signature could be shown along
> +with the remote it came from.

For the MVP, do we need this?

Show 11 quoted lines

> +Implementation Exploration: Check special config branch at fetch time
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +* Perform fetch as normal
> +
> +* After fetch is complete, Git checks for a "magic" config branch (e.g.
> ++origin/refs/recommended-config+) which contains information about config lines
> +an end-user may want, including hooks.
> +
> +* As part of the fetch subcommand, Git alerts users (but not interactively) they
> +can install install the configs contained there.

This doesn't describe what the "magic" ref points to, but it could point to a tree containing the hooks.