On Wed, Feb 14, 2018 at 03:02:00AM +0100, Leo Gaspard wrote: > > So does anybody actually want to be able to adjust the refs as they pass > > through? It really sounds like you just want to be able to reject or not > > reject the fetch. And that rejecting would be the uncommon case, so it's > > OK to just abort the whole operation and expect the user to figure it > > out. > > This completely fits my use case (modulo the fact that it's more similar > to the `update` hook than to `pre-receive` I think, as verifying the > signature requires the objects to already have been downloaded), indeed, > though I'm not sure it would have fit Joey's (based on my understanding, > adding a merge was what was originally asked for). > > Actually, I'm wondering if the existing semantics of `update` could not > be reused for the `pre-fetch`. Would it make sense to just call `update` > during a fetch in the same way as during a receive-pack? That said it > likely makes this a breaking change, though it's maybe unlikely that a > repository is used both for fetching and for receive-pack'ing, it could > happen. > > So the proposal as I understand it would currently be adding a > `fetch-update` hook that does exactly the same thing as `update` but for > `fetch`. This solves my use case in a nice way, though it likely doesn't > solve Joey's original one (which has been taken care of by a wrapper > since then). > > What do you all think about it? I think it should be a separate hook; having an existing hook trigger in new places is likely to cause confusion and regressions. 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. :) -Peff
