{"thread":{"id":"42119","subject":"RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*","startedAt":"2016-04-22T23:51:06Z","lastAt":"2016-04-26T21:52:02Z","messageCount":8,"participants":["Ævar Arnfjörð Bjarmason","Junio C Hamano","Marc Branchaud","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"284214","messageId":"CACBZZX6j6q2DUN_Z-Pnent1u714dVNPFBrL_PiEQyLmCzLUVxg@mail.gmail.com","threadId":"42119","inReplyTo":null,"subject":"RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2016-04-22T23:51:06Z","receivedAt":"2016-04-22T23:51:06Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, Apr 23, 2016 at 1:33 AM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> Change the hardcoded lookup for .git/hooks/* to optionally lookup in\n> $(git config core.hooksDirectory)/* instead if that config key is set.\n\nI think this'll do for my use-case, but I started with a rather more\nambitious patch that I could forsee not finishing today.\n\nI wanted to support executing e.g. the pre-commit hook, in order, from any of:\n\n    .git/hooks/pre-commit\n    .git/hooks/pre-commit.d/*\n     [We could add some ~-wide path here I guess...]\n     /etc/git/hooks/pre-commit\n     /etc/git/hooks/pre-commit.d/*\n\nWhere the * would be resolved in glob() order.\n\nThe motivation was solving the use-case I'm solving with\ncore.hooksDirectory, perhaps with a config variable to set whether you\nwanted to skip per-repo or system-wide hooks, but also having\nsomething more general.\n\nThe reason for supporting the *.d directories was that I spotted a lot\nof hooks people had hacked up at work using the pee(1) command[1] to\nrun sequences of other unrelated hook commands.\n\nJust symlinking stuff is simpler and more portable if we do the work\nin git.git once. We'd run  The pee(1) command also doesn't quit on the\nfirst command that returns nonzero, which would make sense e.g. for\npre-commit hooks.\n\nI have it working for the hooks that use the simple run_hook_ve()\ninterface, but the ones that have to e.g. pass input on stdin just\nfind_hook() directly & do a custom run_command(), so all of those\ncallsites would have to be patched and/or I'd have to hack up some\ncustom callback mechanism.\n\n1. http://manpages.ubuntu.com/manpages/xenial/en/man1/pee.1.html\n"},{"id":"284456","messageId":"xmqq4mapmvjq.fsf@gitster.mtv.corp.google.com","threadId":"42119","inReplyTo":"CACBZZX6j6q2DUN_Z-Pnent1u714dVNPFBrL_PiEQyLmCzLUVxg@mail.gmail.com","subject":"Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-25T17:45:45Z","receivedAt":"2016-04-25T17:45:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> The reason for supporting the *.d directories was that I spotted a lot\n> of hooks people had hacked up at work using the pee(1) command[1] to\n> run sequences of other unrelated hook commands.\n\nIIRC, we wanted to do this several years ago but after discussion\ndecided that we didn't want to have this in the core, because we\ndidn't want to hardcode the policy on interaction among multiple\nhooks.\n\nYou can easily resolve the ordering of hooks--just declare that they\nare executed sequentially in strcmp() order of filenames and users\nwill know to prefix them with fixed-number-of-digits to force their\ndesired ordering without complaining.\n\nWhat is harder and the core part cannot unilaterally dictate is what\nshould happen after seeing a failure/rejection from a hook.  Some\nhooks among the remainder would not want to be even called.  Some\nothers do want to be called but want to learn that the previous\nhooks already have decided to fail/reject the operation.  There may\neven be some others that cannot be moved to earlier part of the hook\nchain for other external constraints (e.g. side effect of some\nprevious hook is part of its input), but would want to override the\nprevious decision to reject and let the operation pass.\n\nI am happy to see that the idea brought back alive again, but I\nthink we prefer this start its life clearly marked as \"highly\nexperimental and subject to change\", then invite interested and\nbrave users who tolerate backward incompatible changes to\nexperiment, in order to allow us to gauge what the right semantics\nand flexibility the users would want.  One way to do so may be an\nopt-in configuration variable e.g. \"experimental.multiHooks\";\nanother may be to implement the logic as a pair of scripts (one for\nthe command line argument variant, the other for stdin variant) and\nship them in contrib/.\n\nThe latter approach (i.e. scripting) might be easier for people to\nexperiment and tweak, and in the olden days that would certainly be\nthe approach would would have taken, but I am not too afraid of\nappearing uninviting to casual scripters anymore these days, so...\n"},{"id":"284520","messageId":"CACBZZX6AYBYeb5S4nEBhYbx1r=icJ81JGYBx5=H4wacPhHjFbQ@mail.gmail.com","threadId":"42119","inReplyTo":"xmqq4mapmvjq.fsf@gitster.mtv.corp.google.com","subject":"Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2016-04-26T10:58:04Z","receivedAt":"2016-04-26T10:58:04Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Apr 25, 2016 at 7:45 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n>\n>> The reason for supporting the *.d directories was that I spotted a lot\n>> of hooks people had hacked up at work using the pee(1) command[1] to\n>> run sequences of other unrelated hook commands.\n>\n> IIRC, we wanted to do this several years ago but after discussion\n> decided that we didn't want to have this in the core, because we\n> didn't want to hardcode the policy on interaction among multiple\n> hooks.\n\nAh, would be interesting to see that discussion if someone knows\nenough to dig it up, didn't find it with some brief searching.\n\n> You can easily resolve the ordering of hooks--just declare that they\n> are executed sequentially in strcmp() order of filenames and users\n> will know to prefix them with fixed-number-of-digits to force their\n> desired ordering without complaining.\n\nIn principle you're describing glob() order here:\nhttp://pubs.opengroup.org/onlinepubs/7908799/xsh/glob.html\n\nWe don't set LC_COLLATE in git so this'll be C order, which I think\nwill just fall back to strcmp().\n\nIf it doesn't and there's a functional difference, I'm not sure, it's\nprobably less confusing to use glob() order, since that's what you'll\nget with shell expansion.\n\nI.e. it would be confusing if you expand the hooks in the shell, and\ngit executes them in a slightly different order.\n\n> What is harder and the core part cannot unilaterally dictate is what\n> should happen after seeing a failure/rejection from a hook.  Some\n> hooks among the remainder would not want to be even called.  Some\n> others do want to be called but want to learn that the previous\n> hooks already have decided to fail/reject the operation.  There may\n> even be some others that cannot be moved to earlier part of the hook\n> chain for other external constraints (e.g. side effect of some\n> previous hook is part of its input), but would want to override the\n> previous decision to reject and let the operation pass.\n\nI think it's fair enough to say that if we had this facility this\nwould be good enough:\n\n * Your hooks are executed in glob() order, local .git first, then /etc/git/...\n\n * If it's a hook like pre-commit that can reject something the first\nhook to fail short-circuits. I.e. none of the rest get executed.\n\n * If it's not a hook like that e.g. post-commit all of the hooks will\nget executed.\n\n * If you need anything more complex you can just wrap your hooks in\nyour own shellscript.\n\nI.e. it takes care of the common case where:\n\n * You just want to execute N hooks and don't want to write a wrapper.\n\n * For pre-* hooks the common case is it doesn't matter /what/\nrejected things, just that it gets rejected, e.g. for pre-receive.\nAlso if you care about performance you can order them in\ncheapest-first order.\n\n> I am happy to see that the idea brought back alive again, but I\n> think we prefer this start its life clearly marked as \"highly\n> experimental and subject to change\", then invite interested and\n> brave users who tolerate backward incompatible changes to\n> experiment, in order to allow us to gauge what the right semantics\n> and flexibility the users would want.  One way to do so may be an\n> opt-in configuration variable e.g. \"experimental.multiHooks\";\n> another may be to implement the logic as a pair of scripts (one for\n> the command line argument variant, the other for stdin variant) and\n> ship them in contrib/.\n\nMakes sense to have an experimental.* config tree for git for stuff like this.\n\n> The latter approach (i.e. scripting) might be easier for people to\n> experiment and tweak, and in the olden days that would certainly be\n> the approach would would have taken, but I am not too afraid of\n> appearing uninviting to casual scripters anymore these days, so...\n\nYeah, actually one thing I didn't think of is that the core.hooksPath\npatch I submitted makes this rather trivial to implement as a\ncollection of scripts...\n"},{"id":"284523","messageId":"571F6FB5.2000305@xiplink.com","threadId":"42119","inReplyTo":"CACBZZX6AYBYeb5S4nEBhYbx1r=icJ81JGYBx5=H4wacPhHjFbQ@mail.gmail.com","subject":"Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2016-04-26T13:40:05Z","receivedAt":"2016-04-26T13:40:05Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 2016-04-26 06:58 AM, Ævar Arnfjörð Bjarmason wrote:\n> \n> Makes sense to have an experimental.* config tree for git for stuff like this.\n\nI disagree.\n\n* If the point is to express some kind of warning to users, I think the\ncommunity has been much better served by leaving experimental settings\nundocumented (or documented only in unmerged topic branches).  It feels like\nan experimental.* tree is a doorway to putting experimental features in\nofficial releases, which seems odd considering that (IMHO) git has so far\ndone very well with the carefully-planned-out integration of all sorts of\nfeatures.\n\n* Part of the experiment is coming up with appropriate configuration knobs,\nincluding where those knobs should live.  Often such considerations lead to a\nbetter implementation for the feature.  Dumping things into an experimental.*\ntree would merely postpone that part of the feature's design.\n\n* Such a tree creates a flag day when the experimental feature eventually\nbecomes a \"real\" feature. That'll annoy any early adopters. Sure, they\n*should* be prepared to deal with config tree bike-shedding, but still that\nextra churn seems unnecessary.\n\n\t\tM.\n"},{"id":"284530","messageId":"CACBZZX6CRBQ5qOBdwamqJMz+_QU-cmVfA7iLTyjOCYentjx-mw@mail.gmail.com","threadId":"42119","inReplyTo":"571F6FB5.2000305@xiplink.com","subject":"Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2016-04-26T16:09:34Z","receivedAt":"2016-04-26T16:09:34Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Apr 26, 2016 at 3:40 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:\n> On 2016-04-26 06:58 AM, Ævar Arnfjörð Bjarmason wrote:\n>>\n>> Makes sense to have an experimental.* config tree for git for stuff like this.\n>\n> I disagree.\n>\n> * If the point is to express some kind of warning to users, I think the\n> community has been much better served by leaving experimental settings\n> undocumented (or documented only in unmerged topic branches).  It feels like\n> an experimental.* tree is a doorway to putting experimental features in\n> official releases, which seems odd considering that (IMHO) git has so far\n> done very well with the carefully-planned-out integration of all sorts of\n> features.\n>\n> * Part of the experiment is coming up with appropriate configuration knobs,\n> including where those knobs should live.  Often such considerations lead to a\n> better implementation for the feature.  Dumping things into an experimental.*\n> tree would merely postpone that part of the feature's design.\n>\n> * Such a tree creates a flag day when the experimental feature eventually\n> becomes a \"real\" feature. That'll annoy any early adopters. Sure, they\n> *should* be prepared to deal with config tree bike-shedding, but still that\n> extra churn seems unnecessary.\n\nBy \"stuff like this\", yeah I did mean, and I assume Junio means,\nputting \"experimental\" features in official releases.\n\nE.g. perl does this, if you type \"perldoc experimental\" on a Linux box\nyou'll get the documentation.\n\nBasically you can look at patches to a project on a spectrum of:\n\n 1. You hacked something up locally\n 2. It's in someone's *.git repo as a POC\n 3. It's a third-party patch series used by a bunch of people\n 4. In an official release but documented as experimental\n 5. In an official release as a first-rate feature\n\nSomething like an experimental.WHATEVER=bool flag provides #4.\n\nI think aside from this feature just leaving these things undocumented\nreally provides the worst of both worlds.\n\nNow you have some feature that's undocumented *because* you're not\nsure about it, but you can't ever be sure about it unless people\nactually use it, and if it's not documented at all effectively it's as\nvisible as some third-party patch series. I.e. only people really\ninvolved in the project will ever use it.\n\nWhich is why perl has the \"experimental\" subsystem, it allows for\nplaying around with features the maintainers aren't quite sure about\nin official releases, and the users know they're opting in to trying\nsomething unstable that may go away or have its semantics changed from\nunder them.\n"},{"id":"284554","messageId":"CAP8UFD37djTYZAeR_vcSf0G49rH=zAmn6nVXj5QG+ozDMD2x-Q@mail.gmail.com","threadId":"42119","inReplyTo":"CACBZZX6CRBQ5qOBdwamqJMz+_QU-cmVfA7iLTyjOCYentjx-mw@mail.gmail.com","subject":"Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2016-04-26T17:52:11Z","receivedAt":"2016-04-26T17:52:11Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Apr 26, 2016 at 6:09 PM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> On Tue, Apr 26, 2016 at 3:40 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:\n>> On 2016-04-26 06:58 AM, Ævar Arnfjörð Bjarmason wrote:\n>>>\n>>> Makes sense to have an experimental.* config tree for git for stuff like this.\n>>\n>> I disagree.\n>>\n>> * If the point is to express some kind of warning to users, I think the\n>> community has been much better served by leaving experimental settings\n>> undocumented (or documented only in unmerged topic branches).\n\nThere are features considered experimental that are documented, like\n--split-index in `git update-index` and `git interpret-trailers`.\n\nAs far as I know the possible reasons they are considered experimental are:\n\n- in the release notes they were described as \"experimental\",\n- they are not considered complete, because of missing features,\n- they might not be useful as is,\n- they might be buggy in the real world.\n\n>> It feels like\n>> an experimental.* tree is a doorway to putting experimental features in\n>> official releases, which seems odd considering that (IMHO) git has so far\n>> done very well with the carefully-planned-out integration of all sorts of\n>> features.\n\nSome people have been happily experimenting with or even using some of\nthe experimental features, like the ones I am talking about above.\n\n>> * Part of the experiment is coming up with appropriate configuration knobs,\n>> including where those knobs should live.\n\nI agree that it can be difficult to find the right knobs for any new feature.\n\n>> Often such considerations lead to a\n>> better implementation for the feature.  Dumping things into an experimental.*\n>> tree would merely postpone that part of the feature's design.\n\nI am not so sure about this. For example `git update-index\n--untracked-cache` used to be considered experimental, but it\ndefinitely had knobs that were not right, so its UI has been reworked\nrecently.\n\nMaybe if it had first been created with an UI in an experimental.*\nconfig tree, rather than only options to `git update-index` it would\nhave been an easier transition.\n\n>> * Such a tree creates a flag day when the experimental feature eventually\n>> becomes a \"real\" feature. That'll annoy any early adopters. Sure, they\n>> *should* be prepared to deal with config tree bike-shedding, but still that\n>> extra churn seems unnecessary.\n\nNot sure about that. New config options outside the experimental.*\nconfig tree could always take over config options in the\nexperimental.* config tree, as if they appear, it means that the user\nis aware that they are the new way to configure the feature. Then the\ncost of supporting both the old options in the experimental.* config\ntree and the new ones outside should be very small, especially if\nthere are not many changes between the two set of options.\n\nIf there are a lot of changes between these two sets, it means that we\nwere probably right to have the old ones in the experimental.* config\ntree. And in the worst case, which should hardly ever happen, we can\nprobably afford to just emit warnings saying \"old 'experimental.XXXX'\nconfig option is not supported anymore, please use YYYY config option\ninstead\" and just ignore the 'experimental.XXXX' config option.\n\n> By \"stuff like this\", yeah I did mean, and I assume Junio means,\n> putting \"experimental\" features in official releases.\n>\n> E.g. perl does this, if you type \"perldoc experimental\" on a Linux box\n> you'll get the documentation.\n>\n> Basically you can look at patches to a project on a spectrum of:\n>\n>  1. You hacked something up locally\n>  2. It's in someone's *.git repo as a POC\n>  3. It's a third-party patch series used by a bunch of people\n>  4. In an official release but documented as experimental\n>  5. In an official release as a first-rate feature\n\nYeah, and it seems to me that Git also has:\n\n4.5. In an official release, documented, but scarcely documented as experimental\n\nand in fact more stuff under 4.5. than under 4.\n\nAnd in Git there is also the notion of porcelain vs plumbing, where\nporcelain output can more easily be changed a bit than plumbing\noutput.\n\n> Something like an experimental.WHATEVER=bool flag provides #4.\n>\n> I think aside from this feature just leaving these things undocumented\n> really provides the worst of both worlds.\n\nYeah I agree. Undocumented stuff in Git is already for stuff that we\ndon't want people to use.\n\n> Now you have some feature that's undocumented *because* you're not\n> sure about it, but you can't ever be sure about it unless people\n> actually use it, and if it's not documented at all effectively it's as\n> visible as some third-party patch series. I.e. only people really\n> involved in the project will ever use it.\n>\n> Which is why perl has the \"experimental\" subsystem, it allows for\n> playing around with features the maintainers aren't quite sure about\n> in official releases, and the users know they're opting in to trying\n> something unstable that may go away or have its semantics changed from\n> under them.\n\nAn \"experimental\" subsystem is perhaps overkill for Git though.\n"},{"id":"284605","messageId":"571FD905.6010705@xiplink.com","threadId":"42119","inReplyTo":"CACBZZX6CRBQ5qOBdwamqJMz+_QU-cmVfA7iLTyjOCYentjx-mw@mail.gmail.com","subject":"Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2016-04-26T21:09:25Z","receivedAt":"2016-04-26T21:09:25Z","isPatch":false,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 2016-04-26 12:09 PM, Ævar Arnfjörð Bjarmason wrote:\n>\n> Basically you can look at patches to a project on a spectrum of:\n>\n>   1. You hacked something up locally\n>   2. It's in someone's *.git repo as a POC\n>   3. It's a third-party patch series used by a bunch of people\n>   4. In an official release but documented as experimental\n>   5. In an official release as a first-rate feature\n>\n> Something like an experimental.WHATEVER=bool flag provides #4.\n\nBut the git project already does #4 without needing a special \nconfiguration tree.  In fact, you ignored the git project's \"pu\" branch \nentirely.  Once a feature gets onto the \"next\" branch, it's already much \nless experimental.  If it needs to put the word \"experimental\" in its \nconfig settings, then maybe shouldn't leave the \"pu\" branch in the first \nplace.\n\n> I think aside from this feature just leaving these things undocumented\n> really provides the worst of both worlds.\n\nYes, I apologize.  I did not mean that things should remain \nundocumented, only that if you're afraid of users harming themselves \nthen you're better off not documenting settings than labelling them as \nexperimental.\n\n> Now you have some feature that's undocumented *because* you're not\n> sure about it, but you can't ever be sure about it unless people\n> actually use it, and if it's not documented at all effectively it's as\n> visible as some third-party patch series. I.e. only people really\n> involved in the project will ever use it.\n\nSlapping \"experimental\" on the configuration only serves to muddy the \nwaters.  Either the feature is good enough to be tried by normal users, \nor it isn't.  If it isn't ready for normal users, let it cook in pu (or \nnext) for a while longer.\n\nGit has got on just fine without having some special designation for \nnot-ready-for-prime-time features, mostly because the development \nprocess lends itself naturally to gradually exposing things as they \nmature: topics move from the list to pu to next to master.  (The string \n\"experiment\" only appears 16 times in all the release notes, which I \nthink is something the git project can be proud of.)\n\nTo me, designating part of the config tree as \"experimental\" enables \nsloppier practices, where a feature can be released with a bit less \neffort than might otherwise be acceptable, because it's clearly marked \nas experimental, and so anyone trying it out surely has the requisite \nbulletproof footwear.  (I don't mean to imply that you or any other git \ncontributor might slack off on any work you do for the project. It's \nmore that the ability to easily designate something as experimental \nlowers the bar a bit, and makes it more tempting to release \nnot-quite-ready features.)\n\nFar better to instead work on the feature until it's as ready as can be, \nand release it properly.\n\nIn this particular case, for example, I think your proposed approach is \nperfectly fine and does not need to be designated as \"experimental\" in \nany way.  With a reasonable \"hooks.something\" config variable to turn on \ndirectory support, what you've described sounds like a great feature. \nSure, it may have bugs, it may have unintended consequences, it may not \nfulfill some odd corner cases.  But that's true for almost everything. \nAs with every other git feature, it'll be developed to the best of the \nproject's abilities and released.  Future patches are welcome.\n\n\t\tM.\n"},{"id":"284608","messageId":"xmqq60v4don1.fsf@gitster.mtv.corp.google.com","threadId":"42119","inReplyTo":"CACBZZX6AYBYeb5S4nEBhYbx1r=icJ81JGYBx5=H4wacPhHjFbQ@mail.gmail.com","subject":"Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-04-26T21:52:02Z","receivedAt":"2016-04-26T21:52:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> I think it's fair enough to say that if we had this facility this\n> would be good enough:\n>\n>  * Your hooks are executed in glob() order, local .git first, then /etc/git/...\n>\n>  * If it's a hook like pre-commit that can reject something the first\n> hook to fail short-circuits. I.e. none of the rest get executed.\n>\n>  * If it's not a hook like that e.g. post-commit all of the hooks will\n> get executed.\n>\n>  * If you need anything more complex you can just wrap your hooks in\n> your own shellscript.\n>\n> I.e. it takes care of the common case where:\n>\n>  * You just want to execute N hooks and don't want to write a wrapper.\n>\n>  * For pre-* hooks the common case is it doesn't matter /what/\n> rejected things, just that it gets rejected, e.g. for pre-receive.\n> Also if you care about performance you can order them in\n> cheapest-first order.\n\nStop using the word \"common\" to describe what is not demonstratably\n\"common\".\n\nThe above only covers a very limited subset of the use cases, which\nis the two bullet points above (one of them i.e. \"I do not bother to\nwrite a wrapper\" is not even a valid use case).  That may be a good\nstarting point, but it is so simple that can be done with a wrapper\nwith several lines at most.  So I am not sympathetic to that line of\nreasoning at all.\n\nI can buy \"It is too cumbersome to require everybody to reinvent and\nscript the cascading logic, and the core side should help by giving\na standard interface that is flexible enough to suit people's need\",\nthough.\n\nAnd I have to say that a sequential execution that always\nshort-circuits at the first failure is below that threshold.\n\nOne reason I care about allowing the users to specify \"do not\nshortcut\" is that I anticipate that people would want to have a\nlogging of the result at the end of the chain.\n"}]}