{"thread":{"id":"57565","subject":"Re: Follow-up on hooks series","startedAt":"2022-03-15T20:25:21Z","lastAt":"2022-03-15T22:38:04Z","messageCount":2,"participants":["Emily Shaffer","rsbecker@nexbridge.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"451427","messageId":"CAJoAoZmBdgFez5Mrx9_GMaNtcTrTixEOjE+Gshs0umTbbXAOPw@mail.gmail.com","threadId":"57565","inReplyTo":"220315.86lexbdm4d.gmgdl@evledraar.gmail.com","subject":"Re: Follow-up on hooks series","fromName":"Emily Shaffer","fromEmail":"emilyshaffer@google.com","sentAt":"2022-03-15T20:25:05Z","receivedAt":"2022-03-15T20:25:21Z","isPatch":false,"sender":{"key":"nasamuffin@google.com","avatar":"https://avatars.githubusercontent.com/u/1606826?v=4"},"body":"As threatened in IRC yesterday, adding Git list as well ;)\n\nOn Tue, Mar 15, 2022 at 12:57 PM Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n>\n>\n> On Mon, Mar 14 2022, rsbecker@nexbridge.com wrote:\n>\n> > 1 I am not sure of the usefulness of the git hook list <hook> form. If you know the name of the hook, then you don’t need it listed. I get that it seems like a whereis style command. How\n> >  about this:\n> >  git hook list [ <hook-pattern> … ]\n> >  that displays all hooks if none specified or those matching a pattern. The current message of hooks in hookdir is not particularly meaningful to me. hook bob found in .git/hooks explicitly\n> >  would be more useful and better if you have patterns.\n>\n> That might be a good idea, I honestly haven't re-paged this into my brain.\n>\n> In any case this isn't in master/next or in-flight, there's just \"git\n> hook run\" there, so let's discuss it when those patches are submitted\n> (I'll CC you).\n\n\nI'm a little unsure about what the semantics of this looks like, actually.\n\nThe way it works as implemented is like so:\n\n$ git list pre-commit\n# Because pre-commit can run more than one script, they all appear in\nthe output:\n/usr/share/some-package/very-cool-pre-commit-hook\n~/my-repo/hooks/project-specific-hook\n~/src/script-i-wrote-to-watch-for-debug-printfs\n\nThat is, I know that I'm about to make a commit, but I don't remember\nif I configured very-cool-pre-commit-hook and I need it for this\ncommit, so I want to list all my pre-commit hooks as a sanity check.\n\nSo I'm a little bit confused why it would be useful to grep with a\npattern. Are you expecting instead for something like:\n$ git hook list '.*project-specific'\npre-commit: ~/my-repo/hooks/project-specific-hook\nprepare-commit-msg: ~/my-repo/hooks/project-specific-check-commit-msg-hook\n\nOr maybe even, given a config:\n[hook \"very-cool\"]\n  command = /usr/share/some-package/very-cool-pre-commit-hook\n  event = pre-commit\n[hook \"very-cool-other-hook\"]\n  command = /usr/share/some-package/very-cool-pre-push-hook\n  event = pre-push\n\nto run something like\n$ git hook list 'very-co*'\nhook.\"very-cool\".command=/usr/share/some-package/very-cool-pre-commit-hook\nhook.\"very-cool\".event=pre-commit\nhook.\"very-cool-other-hook\".command=/usr/share/some-package/very-cool-pre-push-hook\nhook.\"very-cool-other-hook\".event=pre-push\n\nBoth these examples I see a little less usefulness, but especially the\nlast one (which is essentially a thinly veiled 'git config\n--get-regexp') doesn't seem useful to me. The \"hook name\" (\"very-cool\"\nand \"very-cool-other-hook\" in this example) is pretty much an\nimplementation detail local to the config parse, and user will never\nrefer to it by that name after the config setup, right?\n\n>\n>\n> > 2 I may have missed something, but I thought that this series might\n> > allow execution of hooks if not in a repository – that was my hope\n> > anyway. To do this, maybe add a --repository=<path> argument so that\n> > git will know where to find the ./git/hooks directory, and then run\n> > it.\n>\n> Yeah, some version of those patches does that, not sure which offhand...\n\nHrm. Well, I have a bit of a personal grudge against .git/hooks/ hooks\nin general :) so I would say, if you will go through the pain of\nwanting to reuse some hook in some specific repo all over your\nmachine, why not just set it up in your ~/.gitconfig instead, so you\ndon't have to pass this argument?\n\nBetter yet, if this argument is targeted for scripting, I think you\ncould achieve the same thing with 'git -c\ncore.hooksPath=~/myproject/.git/hooks/ hook run sendemail-validate',\nand we wouldn't have to implement anything new at all.\n\n - Emily\n"},{"id":"451450","messageId":"032501d838bd$5174c090$f45e41b0$@nexbridge.com","threadId":"57565","inReplyTo":"CAJoAoZmBdgFez5Mrx9_GMaNtcTrTixEOjE+Gshs0umTbbXAOPw@mail.gmail.com","subject":"RE: Follow-up on hooks series","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-03-15T22:37:51Z","receivedAt":"2022-03-15T22:38:04Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On March 15, 2022 4:25 PM, Emily Shaffer wrote:\n>As threatened in IRC yesterday, adding Git list as well ;)\n\nCC'ing the Git list as agreed 😊\n\n>On Tue, Mar 15, 2022 at 12:57 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n>wrote:\n>> On Mon, Mar 14 2022, rsbecker@nexbridge.com wrote:\n>>\n>> > 1 I am not sure of the usefulness of the git hook list <hook> form.\n>> > If you know the name of the hook, then you don’t need it listed. I get that it\n>seems like a whereis style command. How  about this:\n>> >  git hook list [ <hook-pattern> … ]\n>> >  that displays all hooks if none specified or those matching a\n>> > pattern. The current message of hooks in hookdir is not particularly meaningful\n>to me. hook bob found in .git/hooks explicitly  would be more useful and better if\n>you have patterns.\n>>\n>> That might be a good idea, I honestly haven't re-paged this into my brain.\n>>\n>> In any case this isn't in master/next or in-flight, there's just \"git\n>> hook run\" there, so let's discuss it when those patches are submitted\n>> (I'll CC you).\n>\n>\n>I'm a little unsure about what the semantics of this looks like, actually.\n>\n>The way it works as implemented is like so:\n>\n>$ git list pre-commit\n># Because pre-commit can run more than one script, they all appear in the output:\n>/usr/share/some-package/very-cool-pre-commit-hook\n>~/my-repo/hooks/project-specific-hook\n>~/src/script-i-wrote-to-watch-for-debug-printfs\n\nI think my issue may be that I do not have a complete set of patches. The tests I ran did not produce output like that. This also may be something to clarify in the documentation - can you post the latest bit?\n\n>That is, I know that I'm about to make a commit, but I don't remember if I\n>configured very-cool-pre-commit-hook and I need it for this commit, so I want to\n>list all my pre-commit hooks as a sanity check.\n>\n>So I'm a little bit confused why it would be useful to grep with a pattern. Are you\n>expecting instead for something like:\n>$ git hook list '.*project-specific'\n>pre-commit: ~/my-repo/hooks/project-specific-hook\n>prepare-commit-msg: ~/my-repo/hooks/project-specific-check-commit-msg-\n>hook\n>\n>Or maybe even, given a config:\n>[hook \"very-cool\"]\n>  command = /usr/share/some-package/very-cool-pre-commit-hook\n>  event = pre-commit\n>[hook \"very-cool-other-hook\"]\n>  command = /usr/share/some-package/very-cool-pre-push-hook\n>  event = pre-push\n>\n>to run something like\n>$ git hook list 'very-co*'\n>hook.\"very-cool\".command=/usr/share/some-package/very-cool-pre-commit-\n>hook\n>hook.\"very-cool\".event=pre-commit\n>hook.\"very-cool-other-hook\".command=/usr/share/some-package/very-cool-\n>pre-push-hook\n>hook.\"very-cool-other-hook\".event=pre-push\n>\n>Both these examples I see a little less usefulness, but especially the last one\n>(which is essentially a thinly veiled 'git config\n>--get-regexp') doesn't seem useful to me. The \"hook name\" (\"very-cool\"\n>and \"very-cool-other-hook\" in this example) is pretty much an implementation\n>detail local to the config parse, and user will never refer to it by that name after\n>the config setup, right?\n\nAs a user of this, what I was looking for was some way to query the inventory of relevant hooks. Assuming the user knows where all the possible hooks are, I guess this is ok.\n\n>> > 2 I may have missed something, but I thought that this series might\n>> > allow execution of hooks if not in a repository – that was my hope\n>> > anyway. To do this, maybe add a --repository=<path> argument so that\n>> > git will know where to find the ./git/hooks directory, and then run\n>> > it.\n>>\n>> Yeah, some version of those patches does that, not sure which offhand...\n>\n>Hrm. Well, I have a bit of a personal grudge against .git/hooks/ hooks in general :)\n>so I would say, if you will go through the pain of wanting to reuse some hook in\n>some specific repo all over your machine, why not just set it up in your ~/.gitconfig\n>instead, so you don't have to pass this argument?\n\nI think the useful case is more sharing hooks between copies of the repo, not sharing hooks between repos of different origins. So ~/.gitconfig is not the place I am likely to put hooks. It's not like I have 50-100 different projects on the fly at once 😉\n\n>Better yet, if this argument is targeted for scripting, I think you could achieve the\n>same thing with 'git -c core.hooksPath=~/myproject/.git/hooks/ hook run\n>sendemail-validate', and we wouldn't have to implement anything new at all.\n\nIsn't that in Ævar series? I don't see it in 2.35.1? I don't think the goal is scripting around git, it is more scripting inside git. The users with whom I work seem to want the least amount of external scripting as possible, mostly because of how they are running git. The model I am working work, which is multi-platform (and not shell-invoked), is to set up a façade that runs git to perform whatever needs to be done, and the hooks offer some good value because we are inside a shell by that point, but not when git gets launched. I know it's funky, but that's why I find the whole series \"interesting\".\n\n-Randall\n\n"}]}