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

On June 18, 2021 5:59 PM, Jonathan Tan wrote:

quoted

quoted

On Wed, Jun 16, 2021 at 04:31:47PM -0700, Jonathan Tan wrote:

quoted

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.