Re: RE: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks

Re: RE: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks

[Jonathan Tan]

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