On 02/07/2018 11:51 PM, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Feb 07 2018, Leo Gaspard jotted: > >> Hello, >> >> tl;dr: Is there currently a way to have fetch hooks, and if not do you >> think it could be a nice feature? >> >> I was in the process of implementing hooks for git that ensure the >> repository is always cleanly signed by someone allowed to by the >> repository itself. I think I've completed the signature-checking part >> [1] and the push hook [2] (even though it isn't really configurable at >> the moment). >> >> However, I was starting to think about handling the fetch step, and >> couldn't find any fetch hook. Is there one? >> >> If not, would you think it is would be a good idea to add one, that >> would eg. be passed the commit-before, commit-after and could block the >> changing of the reference if it failed? >> >> The only other solution I could think of is using a separate script for >> fetching, but that would be fragile, as the user could always not think >> about it well and run a git fetch, breaking the objective that after the >> first clone all commits were correctly signature-checked. >> >> Thanks for reading me! >> Leo >> >> PS1: I am not subscribed to the ML. >> >> PS2: I've tried asking freenode#git, without success so far. >> >> >> [1] >> https://github.com/Ekleog/signed-git/blob/master/git-hooks/check-range-signed.sh >> >> [2] https://github.com/Ekleog/signed-git/blob/master/git-hooks/pre-push > > There is no fetch hook, however you may find that the > post-{checkout,merge} hooks are suitable for what you want to do. > > Setting those to some custom comand is a common pattern for > e.g. compiling some assets on "git pull", so you could similarly check > the commits from HEAD, of course those are post-* hooks, so they won't > stop the checkout. Hmm, I don't think these would fit the bill. For post-merge, simply because I spend my life rebasing stuff around, and very rarely merge. For post-checkout, it could work, but then I'd need to keep track manually of up to where the commits have been checked and to search the git graph for the latest checked ancestor (as otherwise checking-out another branch then checking-out the first branch again would likely trigger a failure, due to the keyring being dynamic), so it would likely be a dealbreaker, due to the hook becoming too complex to be trusted. (Just in case you wonder, by “the keyring being dynamic” I mean the PGP keys allowed to sign commits are stored directly inside the git repository) That said, I just came upon [1] (esp. the description [2] and the patch [3]), and wondered: it looks like the patch was abandoned midway in favor of a hook refactoring. Would you happen to know whether the hook refactoring eventually took place, and/or whether this patch was resubmitted later, and/or whether it would still be possible to merge this now? (not having any experience with git's internals yet, I don't really know whether these are stupid questions or not) Thanks! Leo PS: Cc'ing Joey, as you most likely know best what eventually happened, if you can remember it? [1] https://marc.info/?t=132477041500001&r=1&w=2 [2] https://marc.info/?l=git&m=132483581218382&w=2 [3] https://marc.info/?l=git&m=132486687023893&w=2
