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? 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
