{"thread":{"id":"55979","subject":"Re: RE: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks","startedAt":"2021-06-21T18:31:15Z","lastAt":"2021-06-21T18:31:15Z","messageCount":1,"participants":["Jonathan Tan"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"428082","messageId":"20210621183109.1165775-1-jonathantanmy@google.com","threadId":"55979","inReplyTo":"020d01d764916fb7520nexbridge.com","subject":"Re: RE: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2021-06-21T18:31:09Z","receivedAt":"2021-06-21T18:31:15Z","isPatch":true,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"> On June 18, 2021 5:59 PM, Jonathan Tan wrote:\n> >> On Wed, Jun 16, 2021 at 04:31:47PM -0700, Jonathan Tan wrote:\n> >> >\n> >> > I have had to make several design choices (which I will discuss\n> >> > later), but now with this implementation, the following workflow is possible:\n> >> >\n> >> >  1. The remote repo administrator creates a new branch\n> >> >     \"refs/heads/suggested-hooks\" pointing to a commit that has all the\n> >> >     hooks that the administrator wants to suggest. The hooks are\n> >> >     directly referenced by the commit tree (i.e. they are in the \"/\"\n> >> >     directory).\n> >>\n> >> I don't really like that this is in the same namespace as branches\n> >> users could create themselves. Hm, I think for 'git maintenance'\n> >> prefetching we put those refs in some special namespace, right? Can we\n> >> do something similar in this case? Would that prevent us from treating\n> >> that ref like a normal branch?\n> >\n> >Do you mean that the server should put it in a different place, the client should put it in a different place, or both?\n> \n> This brings up a very awkward question: How are enterprise git servers going\n> to deal with this?\n\nWhat do you mean by \"this\"?\n\n> I do not see the standard Pull Request mechanism available in GitHub handing\n> placing hooks in different places during a merge operation. Or will this\n> entire concept be omitted from PR?\n> \n> It seems like changes to hooks have to be managed in a similar way to\n> standard managed files rather than as exceptions.\n> \n> -Randall\n\nThe plan in this RFC is to manage the changes in hooks just like any\nother branch - to update a hook, you can make a PR against\nrefs/heads/suggested-hooks.\n"}]}