On Mon, Feb 19, 2018 at 2:50 PM, Leo Gaspard <leo@xxxxxxxxxx> wrote: > On 02/19/2018 10:23 PM, Jeff King wrote: >> [...] >> If you do go this route, please model it after "pre-receive" rather than >> "update". We had "update" originally but found it was too limiting for >> hooks to see only one ref at a time. So we introduced pre-receive. The >> "update" hook remains for historical reasons, but I don't think we'd >> want to reproduce the mistake. :) > > Hmm, what bothered me with “pre-receive” was that it was an > all-or-nothing decision, without the ability to allow some references > through and not others. > > Is there a way for “pre-receive” to individually filter hooks? I was > under the impression that the only way to do that was to use the > “update” hook, which was the reason I wanted to model it after “update” > rather than “pre-receive” (my use case being a check independent for > each pushed ref) At least in the "push" case I think there is value in saying "if one ref fails, please fail the entire push, always". This makes sense, because if a user happens to violate some rule in one thing, they very likely may not wish any of the push to succeed, and it also creates problems with whether a push is atomic or not. For fetch, I could see either method being useful. Thanks, Jake
