Re: Fetch-hooks

From: Jacob Keller <jacob.keller@gmail.com>
Date: Feb 20, 2018, 06:10 UTC
Message-ID: <CA+P7+xrb0PCsJtQbrT+E9hNhZ8yZ5qeR7vVGVYFtqEOeoK77kw@mail.gmail.com>
In-Reply-To: <cdef8e46-92ee-2062-385a-999b5b49ae9a@gaspard.io>

On Mon, Feb 19, 2018 at 2:50 PM, Leo Gaspard <leo@gaspard.io> wrote:

Show 17 quoted lines

> 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