On Thu, 18 Mar 2021 at 21:29, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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.
