On 2021-08-21 at 20:00:07, Rafael Santiago via GitGitGadget wrote: > From: rafael-santiago <voidbrainvoid@xxxxxxxxxxxx> > > 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
Attachment:
signature.asc
Description: PGP signature
