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

[Ed Maste <emaste@freebsd.org>]

On Thu, 18 Mar 2021 at 21:29, brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> > +* Works across Windows/Linux/macOS
>
> Git supports other platforms as well.

In particular, FreeBSD is an example of a platform that is not in the
above list, but included in Git's CI. Is there an explicit list of
supported platforms (and perhaps a notion of support tiers)?

On Wed, 7 Apr 2021 at 09:09, Derrick Stolee <stolee@gmail.com> wrote:
>
> Here are the hard lines I draw:
>
> 1. This should not happen in "git clone" (other than maybe a message
>    over stderr that hooks are available to be configured through a
>    different command).
>
> 2. Hooks should not update in "git checkout" (other than a message
>    that hooks have updated).
>
> 3. Whatever document triggers a hook configuration should live at
>    HEAD and should not be configured or updated until HEAD has been
>    updated by one Git command (git clone, git checkout), time
>    passes for the user to inspect the worktree, then _another_
>    command (git hooks?) is run manually to reconfigure the hooks.
>
> I think there is a potential way forward if these items are followed.
>
> But I'd like to ask a different question: What problems are these
> custom hooks solving, and can Git solve those problems in-core?

I was looking for repository-provided local hook support for the
FreeBSD repositories, and came across this proposal. I'll explain our
desire, in case it can provide some insight. (We started migrating
from Subversion to Git some time ago and finished the last repo a
couple of weeks ago.)

We use one hook today, and would like developers to keep it up to
date: prepare-commit-msg. We have some standard commit message
trailers like Reviewed by: and Differential Revision: that are
provided as templates, and our prepare-commit-msg adds these to the
default git-provided message that lists changed files and such. These
trailers are updated occasionally - for example, we recently adopted
"Fixes:" and added it to the template.

For us, I think a message that hooks are available or updated, and a
command to install or update them would be fine. I can foresee some
usability concern when switching branches - for example, to an older
release branch, but it's probably not a large concern.

> There is always the extreme option of requiring users to use a
> specific fork of Git in order to work with your repository.

FreeBSD effectively did this when we used Subversion - the modified
commit message template was provided by a patched Subversion via our
ports collection. As you suggested it's workable, but not great.