All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Jonathan Tan'" <jonathantanmy@google.com>, <emilyshaffer@google.com>
Cc: <git@vger.kernel.org>
Subject: RE: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks
Date: Fri, 18 Jun 2021 18:32:41 -0400	[thread overview]
Message-ID: <020d01d76491$dcfe7c60$96fb7520$@nexbridge.com> (raw)
In-Reply-To: <20210618215848.794617-1-jonathantanmy@google.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? 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


  reply	other threads:[~2021-06-18 22:32 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16 23:31 [RFC PATCH 0/2] MVP implementation of remote-suggested hooks Jonathan Tan
2021-06-16 23:31 ` [RFC PATCH 1/2] hook: move list of hooks Jonathan Tan
2021-06-18 20:59   ` Emily Shaffer
2021-06-18 21:48     ` Jonathan Tan
2021-06-16 23:31 ` [RFC PATCH 2/2] clone,fetch: remote-suggested auto-updating hooks Jonathan Tan
2021-06-18 21:32   ` Emily Shaffer
2021-06-17  1:30 ` [RFC PATCH 0/2] MVP implementation of remote-suggested hooks Junio C Hamano
2021-06-18 21:46   ` Jonathan Tan
2021-06-18 20:57 ` Emily Shaffer
2021-06-18 21:58   ` Jonathan Tan
2021-06-18 22:32     ` Randall S. Becker [this message]
2021-06-19  7:58       ` Matt Rogers
2021-06-21 18:37         ` Jonathan Tan
2021-06-20 19:51 ` Ævar Arnfjörð Bjarmason
2021-06-21 18:58   ` Jonathan Tan
2021-06-21 19:35     ` Ævar Arnfjörð Bjarmason
2021-06-22  1:27       ` Jonathan Tan
2021-06-22  0:40   ` brian m. carlson
2021-06-23 22:58     ` Jonathan Tan
2021-06-24 23:11       ` brian m. carlson
2021-06-28 23:12     ` Junio C Hamano
2021-07-16 17:57 ` [RFC PATCH v2 " Jonathan Tan
2021-07-16 17:57   ` [RFC PATCH v2 1/2] hook: move list of hooks Jonathan Tan
2021-07-16 17:57   ` [RFC PATCH v2 2/2] hook: remote-suggested hooks Jonathan Tan
2021-07-19 21:28     ` Junio C Hamano
2021-07-20 21:11       ` Jonathan Tan
2021-07-20 21:28         ` Phil Hord
2021-07-20 21:56           ` Jonathan Tan
2021-07-20 20:55     ` Ævar Arnfjörð Bjarmason
2021-07-20 21:48       ` Jonathan Tan
2021-07-27  0:57         ` Emily Shaffer
2021-07-27  1:29           ` Junio C Hamano
2021-07-27 21:39             ` Jonathan Tan
2021-07-27 22:40               ` Junio C Hamano
2021-07-19 21:06   ` [RFC PATCH v2 0/2] MVP implementation of " Junio C Hamano
2021-07-20 20:49     ` Jonathan Tan

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='020d01d76491$dcfe7c60$96fb7520$@nexbridge.com' \
    --to=rsbecker@nexbridge.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.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.