Re: RE: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks
- From
- Jonathan Tan <jonathantanmy@google.com>
- Date
- Jun 21, 2021, 18:31 UTC
- Message-ID
- <20210621183109.1165775-1-jonathantanmy@google.com>
- In-Reply-To
- <020d01d764916fb7520nexbridge.com>
Show 22 quoted lines
> 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"?
Show 8 quoted lines
> 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.