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

>
> > +* 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.
>

> > +Feature Requirements
> > +~~~~~~~~~~~~~~~~~~~~
> > +
> > +Minimum Feature Set
> > +^^^^^^^^^^^^^^^^^^^
>
> [snip]
>
> > +* 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?
>

> > +* 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?
>

> > +* 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.
>

> > +* 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?
>