In my opinion "binary hooks" (hooks that execute specific binaries not present in the system as a default tool) should be versioned and built as a support tool into the repository or in the worst case downloaded from somewhere, even because versioning binaries into git repos is considered a bad practice that could make bloated repos. The point is that in many cases a dependency with a script language is created only to make the hook actions portable from a platform to other, but what this script in its essence does is a thing that could be done with basic tools delivered with the current operating system. There is no problem on using cygwin on windows, you should use standard hook and do all the effort to make it unique for cygwin environments and true unix boxes (in other words: you would continue doing what you are doing, because it attends yours requirements). Notice that everything that have been working will stay working as before. Anyway, if cygwin becomes a point of incompatibility at some point, you could use the "_windows" version by coding your "cygwin script" there. Maybe this would add more possibilities in git-hook tooling by making them less plastered, I think. Rafael Santiago -- 21 de ago. de 2021 18:50 por sandals@xxxxxxxxxxxxxxxxxxxx: > 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 >
