Re: [PATCH] Give support for hooks based on platform

On 2021-08-21 at 20:00:07, Rafael Santiago via GitGitGadget wrote:

From: rafael-santiago <redacted>

The idea behind this commit can be useful for teams
that share git-hooks into a custom directory and
dealing with projects that must be developed,
built, maintained on several different platforms.

This commit allows the execution of git hooks
based on the current operating system.
A "native hook" is defined in the form:
    hooks/hook-name_platform
Where platform must be equivalent to the
content returned in sysname field in utsname
struct when calling uname() [but all normalized
in lowercase].

On Windows, independent of version, flavor, SP,
whatever it is simply "windows".

I'm not sure that this is going to work out very well.  The MINGW
environment used by Git for Windows and Cygwin are quite different.  I
would fully expect to write shell scripts and Unix tooling in Cygwin,
whereas users using Git for Windows might not want that at all.  That
also doesn't take into effect using Git for Windows in WSL, which
introduces some interesting logistical challenges.

In addition, I have a few concerns about the grouping of Linux
altogether.  While in many cases it is possible to write tooling that
works natively across Linux distros, most binaries will not.  Therefore,
binary hooks that might run fine on Debian would fail on a Fedora or Red
Hat system, especially if those binaries link to any of a number of
different shared libraries (e.g., OpenSSL).

There's also work to move hooks into the config and out of the hooks
directory, and I don't think this will mesh well with it.

The main motivation of this extension is to
reduce dependency of scripting languages,
logical trinkets etc just to execute minor
tasks during scm events that could be done
natively but differently from a platform
to another. Less dependencies, cleaner
repos: a small step for a better world
for any software developer.

Is there a reason that the proper hooks couldn't be copied or symlinked
into place with a script?  I think that would resolve this concern with
a lot less work.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA