All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Tan <jonathantanmy@google.com>
To: rsbecker@nexbridge.com
Cc: jonathantanmy@google.com, emilyshaffer@google.com, git@vger.kernel.org
Subject: Re: RE: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks
Date: Mon, 21 Jun 2021 11:31:09 -0700	[thread overview]
Message-ID: <20210621183109.1165775-1-jonathantanmy@google.com> (raw)
In-Reply-To: <020d01d764916fb7520nexbridge.com>

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

           reply	other threads:[~2021-06-21 18:31 UTC|newest]

Thread overview: expand[flat|nested]  mbox.gz  Atom feed
 [parent not found: <020d01d764916fb7520nexbridge.com>]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210621183109.1165775-1-jonathantanmy@google.com \
    --to=jonathantanmy@google.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=rsbecker@nexbridge.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.