> On June 18, 2021 5:59 PM, Jonathan Tan wrote: > >> On Wed, Jun 16, 2021 at 04:31:47PM -0700, Jonathan Tan wrote: > >> > > >> > I have had to make several design choices (which I will discuss > >> > later), but now with this implementation, the following workflow is possible: > >> > > >> > 1. The remote repo administrator creates a new branch > >> > "refs/heads/suggested-hooks" pointing to a commit that has all the > >> > hooks that the administrator wants to suggest. The hooks are > >> > directly referenced by the commit tree (i.e. they are in the "/" > >> > directory). > >> > >> I don't really like that this is in the same namespace as branches > >> users could create themselves. Hm, I think for 'git maintenance' > >> prefetching we put those refs in some special namespace, right? Can we > >> do something similar in this case? Would that prevent us from treating > >> that ref like a normal branch? > > > >Do you mean that the server should put it in a different place, the client should put it in a different place, or both? > > This brings up a very awkward question: How are enterprise git servers going > to deal with this? What do you mean by "this"? > I do not see the standard Pull Request mechanism available in GitHub handing > placing hooks in different places during a merge operation. Or will this > entire concept be omitted from PR? > > It seems like changes to hooks have to be managed in a similar way to > standard managed files rather than as exceptions. > > -Randall The plan in this RFC is to manage the changes in hooks just like any other branch - to update a hook, you can make a PR against refs/heads/suggested-hooks.
