{"thread":{"id":"56343","subject":"[PATCH] Give support for hooks based on platform","startedAt":"2021-08-21T20:00:21Z","lastAt":"2021-08-23T18:32:43Z","messageCount":9,"participants":["Rafael Santiago via GitGitGadget","brian m. carlson","Rafael Santiago","Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"433312","messageId":"pull.1069.git.git.1629576007891.gitgitgadget@gmail.com","threadId":"56343","inReplyTo":null,"subject":"[PATCH] Give support for hooks based on platform","fromName":"Rafael Santiago via GitGitGadget","fromEmail":"gitgitgadget@gmail.com","sentAt":"2021-08-21T20:00:07Z","receivedAt":"2021-08-21T20:00:21Z","isPatch":true,"sender":{"key":"voidbrainvoid@tutanota.com","avatar":null},"body":"From: rafael-santiago <voidbrainvoid@tutanota.com>\n\nThe idea behind this commit can be useful for teams\nthat share git-hooks into a custom directory and\ndealing with projects that must be developed,\nbuilt, maintained on several different platforms.\n\nThis commit allows the execution of git hooks\nbased on the current operating system.\nA \"native hook\" is defined in the form:\n    hooks/hook-name_platform\nWhere platform must be equivalent to the\ncontent returned in sysname field in utsname\nstruct when calling uname() [but all normalized\nin lowercase].\n\nOn Windows, independent of version, flavor, SP,\nwhatever it is simply \"windows\".\n\nWhen a native hook is not found the standard\nhook (.git/hook/hook-name), if found is executed,\nof course. In other words, the hook without a\nplatform postfix (_yyz) is the standard hook.\nWhen native hook is not set as executable but\nstandard is set, the standard will be executed.\n\nThe main motivation of this extension is to\nreduce dependency of scripting languages,\nlogical trinkets etc just to execute minor\ntasks during scm events that could be done\nnatively but differently from a platform\nto another. Less dependencies, cleaner\nrepos: a small step for a better world\nfor any software developer.\n\nSigned-off-by: Rafael Santiago <voidbrainvoid@tutanota.com>\n---\n    Give support for hooks based on platform\n    \n    The idea behind this commit can be useful for teams that share git-hooks\n    into a custom directory and dealing with projects that must be\n    developed, built, maintained on several different platforms.\n    \n    This commit allows the execution of git hooks based on the current\n    operating system. A \"native hook\" is defined in the form:\n    hooks/hook-name_platform\n    \n    Where platform must be equivalent to the content returned in sysname\n    field in utsname struct when calling uname() [but all normalized in\n    lowercase].\n    \n    On Windows, independent of version, flavor, SP, whatever it is simply\n    \"windows\".\n    \n    When a native hook is not found the standard hook (.git/hook/hook-name),\n    if found is executed, of course. In other words, the hook without a\n    platform postfix (_yyz) is the standard hook. When native hook is not\n    set as executable but standard is set, the standard will be executed.\n    \n    The main motivation of this extension is to reduce dependency of\n    scripting languages, logical trinkets etc just to execute minor tasks\n    during scm events that could be done natively but differently from a\n    platform to another. Less dependencies, cleaner repos: a small step for\n    a better world for any software developer.\n\nPublished-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1069%2Frafael-santiago%2Fmaster-v1\nFetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1069/rafael-santiago/master-v1\nPull-Request: https://github.com/git/git/pull/1069\n\n run-command.c                     | 41 ++++++++++++++++++++\n t/t7527-pre-commit-native-hook.sh | 63 +++++++++++++++++++++++++++++++\n 2 files changed, 104 insertions(+)\n create mode 100755 t/t7527-pre-commit-native-hook.sh\n\ndiff --git a/run-command.c b/run-command.c\nindex f72e72cce73..973c1a3434b 100644\n--- a/run-command.c\n+++ b/run-command.c\n@@ -1319,9 +1319,50 @@ int async_with_fork(void)\n #endif\n }\n \n+static inline const char *platform_name(void)\n+{\n+\tstatic const char *platform = NULL;\n+#ifndef GIT_WINDOWS_NATIVE\n+\tstatic struct utsname un = { 0 };\n+#endif\n+\tif (platform != NULL)\n+\t\treturn platform;\n+\n+#ifndef GIT_WINDOWS_NATIVE\n+\tif (uname(&un) == 0) {\n+\t\tfor (size_t s = 0; un.sysname[s] != 0; s++)\n+\t\t\tun.sysname[s] = tolower(un.sysname[s]);\n+\t\tplatform = un.sysname;\n+\t}\n+#else\n+    platform = \"windows\";\n+#endif\n+\n+    return platform;\n+}\n+\n+static const char *find_native_hook(const char *name)\n+{\n+\tchar native_name[64] = \"\";\n+\tconst char *platform = NULL;\n+\tif (name == NULL || strstr(name, \"_\") != NULL)\n+\t\treturn NULL;\n+\n+\tplatform = platform_name();\n+\tif (platform == NULL)\n+\t\treturn NULL;\n+\n+\tif (snprintf(native_name, sizeof(native_name) - 1, \"%s_%s\", name, platform) >= sizeof(native_name) - 1)\n+\t\treturn NULL;\n+\treturn find_hook(native_name);\n+}\n+\n const char *find_hook(const char *name)\n {\n+\tconst char *native_hook = find_native_hook(name);\n \tstatic struct strbuf path = STRBUF_INIT;\n+\tif (native_hook != NULL)\n+\t\treturn native_hook;\n \n \tstrbuf_reset(&path);\n \tstrbuf_git_path(&path, \"hooks/%s\", name);\ndiff --git a/t/t7527-pre-commit-native-hook.sh b/t/t7527-pre-commit-native-hook.sh\nnew file mode 100755\nindex 00000000000..f3835f943af\n--- /dev/null\n+++ b/t/t7527-pre-commit-native-hook.sh\n@@ -0,0 +1,63 @@\n+#!/bin/sh\n+\n+test_description='Test native hooks extension'\n+\n+. ./test-lib.sh\n+\n+expected_platform=$(uname -s | tr A-Z a-z)\n+\n+if [ $(expr substr $(uname -s | tr A-Z a-z) 1 5) == \"mingw\" ] ; then\n+    expected_platform=\"windows\"\n+fi\n+\n+test_expect_success 'set standard and native pre-commit hooks' '\n+\tmkdir -p test-repo &&\n+\tcd test-repo &&\n+\tgit init &&\n+\tmkdir -p .git/hooks &&\n+\techo \\#!/bin/sh > .git/hooks/pre-commit &&\n+\techo echo Hello generic. >> .git/hooks/pre-commit &&\n+\tchmod u+x .git/hooks/pre-commit &&\n+\techo \\#!/bin/sh > .git/hooks/pre-commit_${expected_platform} &&\n+\techo echo Hello ${expected_platform} >> .git/hooks/pre-commit_${expected_platform} &&\n+\tchmod u+x .git/hooks/pre-commit_${expected_platform} &&\n+\techo test > README &&\n+\tgit add README &&\n+\tgit commit -am \"1-2-3 this is a test.\" 2>out.txt &&\n+\tcat out.txt | grep Hello\\ ${expected_platform}\n+'\n+\n+if [ ${expected_platform} != \"windows\" ] ; then\n+\t# chmod does not work well on Windows.\n+\ttest_expect_success 'set standard and native pre-commit hooks but let the native one not executable' '\n+\t\tmkdir -p test-repo &&\n+\t\tcd test-repo &&\n+\t\tgit init &&\n+\t\tmkdir -p .git/hooks &&\n+\t\techo \\#!/bin/sh > .git/hooks/pre-commit &&\n+\t\techo echo Hello generic. >> .git/hooks/pre-commit &&\n+\t\tchmod u+x .git/hooks/pre-commit &&\n+\t\techo \\#!/bin/sh > .git/hooks/pre-commit_${expected_platform} &&\n+\t\techo echo Hello ${expected_platform} >> .git/hooks/pre-commit_${expected_platform} &&\n+\t\techo test > README &&\n+\t\tgit add README &&\n+\t\tgit commit -am \"1-2-3 this is a test.\" 2>out.txt &&\n+\t\tcat out.txt | grep Hello\\ generic\n+\t'\n+\n+\ttest_expect_success 'set standard pre-commit hook only' '\n+\t\tmkdir -p test-repo &&\n+\t\tcd test-repo &&\n+\t\tgit init &&\n+\t\tmkdir -p .git/hooks &&\n+\t\techo \\#!/bin/sh > .git/hooks/pre-commit &&\n+\t\techo echo Hello standard hook. >> .git/hooks/pre-commit &&\n+\t\tchmod u+x .git/hooks/pre-commit &&\n+\t\techo test > README &&\n+\t\tgit add README &&\n+\t\tgit commit -am \"1-2-3 this is a test.\" 2>out.txt &&\n+\t\tcat out.txt | grep Hello\\ standard\\ hook\n+\t'\n+fi\n+\n+test_done\n\nbase-commit: 225bc32a989d7a22fa6addafd4ce7dcd04675dbf\n-- \ngitgitgadget\n"},{"id":"433313","messageId":"YSF1GfpHXRrXebsB@camp.crustytoothpaste.net","threadId":"56343","inReplyTo":"pull.1069.git.git.1629576007891.gitgitgadget@gmail.com","subject":"Re: [PATCH] Give support for hooks based on platform","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-08-21T21:50:17Z","receivedAt":"2021-08-21T21:50:25Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-08-21 at 20:00:07, Rafael Santiago via GitGitGadget wrote:\n> From: rafael-santiago <voidbrainvoid@tutanota.com>\n> \n> The idea behind this commit can be useful for teams\n> that share git-hooks into a custom directory and\n> dealing with projects that must be developed,\n> built, maintained on several different platforms.\n> \n> This commit allows the execution of git hooks\n> based on the current operating system.\n> A \"native hook\" is defined in the form:\n>     hooks/hook-name_platform\n> Where platform must be equivalent to the\n> content returned in sysname field in utsname\n> struct when calling uname() [but all normalized\n> in lowercase].\n>\n> On Windows, independent of version, flavor, SP,\n> whatever it is simply \"windows\".\n\nI'm not sure that this is going to work out very well.  The MINGW\nenvironment used by Git for Windows and Cygwin are quite different.  I\nwould fully expect to write shell scripts and Unix tooling in Cygwin,\nwhereas users using Git for Windows might not want that at all.  That\nalso doesn't take into effect using Git for Windows in WSL, which\nintroduces some interesting logistical challenges.\n\nIn addition, I have a few concerns about the grouping of Linux\naltogether.  While in many cases it is possible to write tooling that\nworks natively across Linux distros, most binaries will not.  Therefore,\nbinary hooks that might run fine on Debian would fail on a Fedora or Red\nHat system, especially if those binaries link to any of a number of\ndifferent shared libraries (e.g., OpenSSL).\n\nThere's also work to move hooks into the config and out of the hooks\ndirectory, and I don't think this will mesh well with it.\n\n> The main motivation of this extension is to\n> reduce dependency of scripting languages,\n> logical trinkets etc just to execute minor\n> tasks during scm events that could be done\n> natively but differently from a platform\n> to another. Less dependencies, cleaner\n> repos: a small step for a better world\n> for any software developer.\n\nIs there a reason that the proper hooks couldn't be copied or symlinked\ninto place with a script?  I think that would resolve this concern with\na lot less work.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"433314","messageId":"Mheyv1D--3-2@tutanota.com","threadId":"56343","inReplyTo":"YSF1GfpHXRrXebsB@camp.crustytoothpaste.net","subject":"Re: [PATCH] Give support for hooks based on platform","fromName":"Rafael Santiago","fromEmail":"voidbrainvoid@tutanota.com","sentAt":"2021-08-21T23:11:27Z","receivedAt":"2021-08-21T23:19:32Z","isPatch":true,"sender":{"key":"voidbrainvoid@tutanota.com","avatar":null},"body":"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.\n\nThe 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.\n\nThere 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.\nMaybe this would add more possibilities in git-hook tooling by making them less plastered, I think.\n\nRafael Santiago\n-- \n21 de ago. de 2021 18:50 por sandals@crustytoothpaste.net:\n\n> On 2021-08-21 at 20:00:07, Rafael Santiago via GitGitGadget wrote:\n>\n>> From: rafael-santiago <voidbrainvoid@tutanota.com>\n>>\n>> The idea behind this commit can be useful for teams\n>> that share git-hooks into a custom directory and\n>> dealing with projects that must be developed,\n>> built, maintained on several different platforms.\n>>\n>> This commit allows the execution of git hooks\n>> based on the current operating system.\n>> A \"native hook\" is defined in the form:\n>>  hooks/hook-name_platform\n>> Where platform must be equivalent to the\n>> content returned in sysname field in utsname\n>> struct when calling uname() [but all normalized\n>> in lowercase].\n>>\n>> On Windows, independent of version, flavor, SP,\n>> whatever it is simply \"windows\".\n>>\n>\n> I'm not sure that this is going to work out very well.  The MINGW\n> environment used by Git for Windows and Cygwin are quite different.  I\n> would fully expect to write shell scripts and Unix tooling in Cygwin,\n> whereas users using Git for Windows might not want that at all.  That\n> also doesn't take into effect using Git for Windows in WSL, which\n> introduces some interesting logistical challenges.\n>\n> In addition, I have a few concerns about the grouping of Linux\n> altogether.  While in many cases it is possible to write tooling that\n> works natively across Linux distros, most binaries will not.  Therefore,\n> binary hooks that might run fine on Debian would fail on a Fedora or Red\n> Hat system, especially if those binaries link to any of a number of\n> different shared libraries (e.g., OpenSSL).\n>\n> There's also work to move hooks into the config and out of the hooks\n> directory, and I don't think this will mesh well with it.\n>\n>> The main motivation of this extension is to\n>> reduce dependency of scripting languages,\n>> logical trinkets etc just to execute minor\n>> tasks during scm events that could be done\n>> natively but differently from a platform\n>> to another. Less dependencies, cleaner\n>> repos: a small step for a better world\n>> for any software developer.\n>>\n>\n> Is there a reason that the proper hooks couldn't be copied or symlinked\n> into place with a script?  I think that would resolve this concern with\n> a lot less work.\n> -- \n> brian m. carlson (he/him or they/them)\n> Toronto, Ontario, CA\n>\n\n"},{"id":"433334","messageId":"YSLKrX/QTZtxBGDz@camp.crustytoothpaste.net","threadId":"56343","inReplyTo":"Mheyv1D--3-2@tutanota.com","subject":"Re: [PATCH] Give support for hooks based on platform","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-08-22T22:07:41Z","receivedAt":"2021-08-22T22:07:50Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-08-21 at 23:11:27, Rafael Santiago wrote:\n> In my opinion \"binary hooks\" (hooks that execute specific binaries not\n> present in the system as a default tool) should be versioned and built\n> as a support tool into the repository or in the worst case downloaded\n> from somewhere, even because versioning binaries into git repos is\n> considered a bad practice that could make bloated repos.\n\nYes, I agree binary hooks should not be checked into the repository.\n\n> The point is that in many cases a dependency with a script language is\n> created only to make the hook actions portable from a platform to\n> other, but what this script in its essence does is a thing that could\n> be done with basic tools delivered with the current operating system.\n\nThen, in general, it can be done in a shell script containing an if-then\nstatement per platform using the native tools, so I'm not seeing the\nparticular reason that this series is necessary if the hooks being\nexecuted aren't binaries.  All systems on which Git runs must contain a\nPOSIX-compatible shell.\n\nCan you explain the rationale for your proposal in more detail so that\nwe can understand why this change is necessary?  Typically this is done\nin the commit message, but I don't think I understand why you want to do\nthis.\n\n> There is no problem on using cygwin on windows, you should use\n> standard hook and do all the effort to make it unique for cygwin\n> environments and true unix boxes (in other words: you would continue\n> doing what you are doing, because it attends yours requirements).\n> Notice that everything that have been working will stay working as\n> before. Anyway, if cygwin becomes a point of incompatibility at some\n> point, you could use the \"_windows\" version by coding your \"cygwin\n> script\" there.\n\nRight, my point is that your commit message proposes using \"windows\" for\nCygwin.  The patch doesn't, but your commit message says that every\nversion of Windows is considered \"windows\".\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"433338","messageId":"MhkY8ud--3-2@tutanota.com","threadId":"56343","inReplyTo":"YSLKrX/QTZtxBGDz@camp.crustytoothpaste.net","subject":"Re: [PATCH] Give support for hooks based on platform","fromName":"Rafael Santiago","fromEmail":"voidbrainvoid@tutanota.com","sentAt":"2021-08-23T01:07:49Z","receivedAt":"2021-08-23T01:07:52Z","isPatch":true,"sender":{"key":"voidbrainvoid@tutanota.com","avatar":null},"body":"Well, you are taking into consideration that every git user that needs to\nautomate some stuff during a scm event will do it from a shell\n(I meant true shell or a mocked up one such as cygwin, msys, etc)\nand it is true, by design.\n\nHowever, not all git users (out unix) uses git from \"bash-like\"\nenvironments. I know people that prefers using it from a well-cooked\nIDE by clicking and dragging things or even from command prompt when\non Windows. Those people are not able to handle some scm event\nautomation as unix users because git hook in its essence presupposes\nthe existence/necessity of a powerful shell (okay, it is possible to\nput a shebang and call a batch file on windows, maybe, but it is a\nlittle clumsy, in my opinion). On Windows, users can do a bunch of stuff\njust by using the ready to go powershell, but open an if/else on a bash\nscript to run a cygwin instance by calling powershell from there is not a\ngood and clean solution for this type of user. Presupposing shell for git,\nlimitates the idea behind the scm event handling with hooks, because\ncurrently it is strongly dependent from shell to work on every git\nsupported platform.\n\nThe idea of having hooks being executed by platform would be the first\nstep to give support to execute commands on scm events without\nobligating users out of a unix have a shell interpreter to access\nnative stuff. Currently, this commit does not implement it but would be\npossible to do and in a  less noisy way for all unix-like stuff. I am not sure\nbut currently a _windows hook out from cygwin would result on a spawn\nerror, would not?\n\nGit hooks are useful features but would be more useful if it breaked up\nthe shell jail. It could make git much more integrated with the current\nplatform.  Being possible to make it powerful as it is on a unix even on\na total different platform as Windows, let's say.\n\nFor sure, this commit are not a \"panacea\" but intends to start making\ngit-hooks more independent from 3rd party software to work on as expected,\non every platform that a git-repo is expected to be handled.\n\nI hope I was clearer from this time.\n\nRafael Santiago\n--\n22 de ago. de 2021 19:07 por sandals@crustytoothpaste.net:\n\n> On 2021-08-21 at 23:11:27, Rafael Santiago wrote:\n>\n>> In my opinion \"binary hooks\" (hooks that execute specific binaries not\n>> present in the system as a default tool) should be versioned and built\n>> as a support tool into the repository or in the worst case downloaded\n>> from somewhere, even because versioning binaries into git repos is\n>> considered a bad practice that could make bloated repos.\n>>\n>\n> Yes, I agree binary hooks should not be checked into the repository.\n>\n>> The point is that in many cases a dependency with a script language is\n>> created only to make the hook actions portable from a platform to\n>> other, but what this script in its essence does is a thing that could\n>> be done with basic tools delivered with the current operating system.\n>>\n>\n> Then, in general, it can be done in a shell script containing an if-then\n> statement per platform using the native tools, so I'm not seeing the\n> particular reason that this series is necessary if the hooks being\n> executed aren't binaries.  All systems on which Git runs must contain a\n> POSIX-compatible shell.\n>\n> Can you explain the rationale for your proposal in more detail so that\n> we can understand why this change is necessary?  Typically this is done\n> in the commit message, but I don't think I understand why you want to do\n> this.\n>\n>> There is no problem on using cygwin on windows, you should use\n>> standard hook and do all the effort to make it unique for cygwin\n>> environments and true unix boxes (in other words: you would continue\n>> doing what you are doing, because it attends yours requirements).\n>> Notice that everything that have been working will stay working as\n>> before. Anyway, if cygwin becomes a point of incompatibility at some\n>> point, you could use the \"_windows\" version by coding your \"cygwin\n>> script\" there.\n>>\n>\n> Right, my point is that your commit message proposes using \"windows\" for\n> Cygwin.  The patch doesn't, but your commit message says that every\n> version of Windows is considered \"windows\".\n> -- \n> brian m. carlson (he/him or they/them)\n> Toronto, Ontario, CA\n>\n\n"},{"id":"433457","messageId":"YSPLnWshLsWlXwUn@coredump.intra.peff.net","threadId":"56343","inReplyTo":"YSLKrX/QTZtxBGDz@camp.crustytoothpaste.net","subject":"Re: [PATCH] Give support for hooks based on platform","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-23T16:23:57Z","receivedAt":"2021-08-23T16:24:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 22, 2021 at 10:07:41PM +0000, brian m. carlson wrote:\n\n> > The point is that in many cases a dependency with a script language is\n> > created only to make the hook actions portable from a platform to\n> > other, but what this script in its essence does is a thing that could\n> > be done with basic tools delivered with the current operating system.\n> \n> Then, in general, it can be done in a shell script containing an if-then\n> statement per platform using the native tools, so I'm not seeing the\n> particular reason that this series is necessary if the hooks being\n> executed aren't binaries.  All systems on which Git runs must contain a\n> POSIX-compatible shell.\n\nThis is my gut feeling, too (whether users know it or not, even on\nWindows most programs specified by config are being run by the shell).\n\nHowever, I do think there is room for Git to make this case a bit\neasier: conditional config includes. Once we are able to specify hooks\nvia config (which is being worked on elsewhere), then we ought to be\nable to implement an includeIf like:\n\n  [includeIf \"uname_s:linux\"]\n  path = linux-hooks.config\n  [includeIf \"uname_s:windows\"]\n  path = windows-hooks.config\n\nThe advantage being that this could apply to _all_ config, and not just\nhooks.\n\nIt may still require fighting over which values should match on cygwin. ;)\n\n-Peff\n"},{"id":"433460","messageId":"xmqqo89oqfuu.fsf@gitster.g","threadId":"56343","inReplyTo":"YSLKrX/QTZtxBGDz@camp.crustytoothpaste.net","subject":"Re: [PATCH] Give support for hooks based on platform","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-23T16:35:05Z","receivedAt":"2021-08-23T16:35:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> Then, in general, it can be done in a shell script containing an if-then\n> statement per platform using the native tools, so I'm not seeing the\n> particular reason that this series is necessary if the hooks being\n> executed aren't binaries.  All systems on which Git runs must contain a\n> POSIX-compatible shell.\n\nWhen we start defining our hooks in the configuration, this may fit\nwith the conditional inclusion of configuration files.  Current\nconditions only can depend on where the repository is, but it is\neasy to imagine that a conditional inclusion based on the value of\nthe configuration variable, so\n\n\t[includeIf \"var:dev.host=mac\"]\n\t\tpath = ...\n\t[includeIf \"var:dev.host=win\"]\n\t\tpath = ...\n\nmight be a way to say \"if the dev.host configuration (presumably set\nin somewhere like /etc/gitconfig or ~/.gitconfig) is set to this\nvalue, take the configuration from the specified path.\n\nIt is up to the project to define the variable they use to switch\non; some project may ship with a set of hooks that can be used on\nboth windows and cygwin at the same time, in which case they do not\nneed the distinction between the two, and some other project may\ncare about the distinction.  Git does not have to impose or enforce\nany policy about the granularity of what \"the platform\" is, with\nsuch a scheme.\n\n"},{"id":"433473","messageId":"xmqqfsv0qby7.fsf@gitster.g","threadId":"56343","inReplyTo":"YSPLnWshLsWlXwUn@coredump.intra.peff.net","subject":"Re: [PATCH] Give support for hooks based on platform","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-08-23T17:59:28Z","receivedAt":"2021-08-23T17:59:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Sun, Aug 22, 2021 at 10:07:41PM +0000, brian m. carlson wrote:\n>\n>> > The point is that in many cases a dependency with a script language is\n>> > created only to make the hook actions portable from a platform to\n>> > other, but what this script in its essence does is a thing that could\n>> > be done with basic tools delivered with the current operating system.\n>> \n>> Then, in general, it can be done in a shell script containing an if-then\n>> statement per platform using the native tools, so I'm not seeing the\n>> particular reason that this series is necessary if the hooks being\n>> executed aren't binaries.  All systems on which Git runs must contain a\n>> POSIX-compatible shell.\n>\n> This is my gut feeling, too (whether users know it or not, even on\n> Windows most programs specified by config are being run by the shell).\n>\n> However, I do think there is room for Git to make this case a bit\n> easier: conditional config includes. Once we are able to specify hooks\n> via config (which is being worked on elsewhere), then we ought to be\n> able to implement an includeIf like:\n>\n>   [includeIf \"uname_s:linux\"]\n>   path = linux-hooks.config\n>   [includeIf \"uname_s:windows\"]\n>   path = windows-hooks.config\n>\n> The advantage being that this could apply to _all_ config, and not just\n> hooks.\n\nHeh, it seems great minds think alike.\n"},{"id":"433478","messageId":"YSPpySdd5qqDeNbm@coredump.intra.peff.net","threadId":"56343","inReplyTo":"xmqqfsv0qby7.fsf@gitster.g","subject":"Re: [PATCH] Give support for hooks based on platform","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-08-23T18:32:41Z","receivedAt":"2021-08-23T18:32:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 23, 2021 at 10:59:28AM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > On Sun, Aug 22, 2021 at 10:07:41PM +0000, brian m. carlson wrote:\n> >\n> >> > The point is that in many cases a dependency with a script language is\n> >> > created only to make the hook actions portable from a platform to\n> >> > other, but what this script in its essence does is a thing that could\n> >> > be done with basic tools delivered with the current operating system.\n> >> \n> >> Then, in general, it can be done in a shell script containing an if-then\n> >> statement per platform using the native tools, so I'm not seeing the\n> >> particular reason that this series is necessary if the hooks being\n> >> executed aren't binaries.  All systems on which Git runs must contain a\n> >> POSIX-compatible shell.\n> >\n> > This is my gut feeling, too (whether users know it or not, even on\n> > Windows most programs specified by config are being run by the shell).\n> >\n> > However, I do think there is room for Git to make this case a bit\n> > easier: conditional config includes. Once we are able to specify hooks\n> > via config (which is being worked on elsewhere), then we ought to be\n> > able to implement an includeIf like:\n> >\n> >   [includeIf \"uname_s:linux\"]\n> >   path = linux-hooks.config\n> >   [includeIf \"uname_s:windows\"]\n> >   path = windows-hooks.config\n> >\n> > The advantage being that this could apply to _all_ config, and not just\n> > hooks.\n> \n> Heh, it seems great minds think alike.\n\nOne important distinction in what you wrote is that you're expecting the\nuser to set dev.host once. That nicely sidesteps any question of \"how\ndoes Git label each platform?\", but it does mean the user has to do that\nsetup manually (which maybe is amortized across many repos, but in\npractice for many people I suspect is no better than them setting up the\ncorrect \"include\" in the first place).\n\nI hoped that by calling it \"uname_s\", it would be clear it was the same\nas \"uname -s\", and then we could blame any naming confusion on the OS. :)\n\nBut even if it is not used for this particular application, I think the\n[includeIf \"var:...\"] you proposed might be a reasonable thing to\nsupport.\n\n-Peff\n"}]}