On Mon, Feb 19, 2018 at 11:50:37PM +0100, Leo Gaspard 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) No, pre-receive is always atomic. However, that may actually be what you want, if the point is to keep untrusted data out of the repository. By rejecting the whole thing, we could in theory keep the objects from entering the repository at all. This is how the push side works via the "quarantine" system (which is explained in git-receive-pack(1)). Fetching doesn't currently quarantine objects, but it probably wouldn't be very hard to make it do so. -Peff
