git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matt Rogers <mattr94@gmail.com>
To: "Randall S. Becker" <rsbecker@nexbridge.com>
Cc: Jonathan Tan <jonathantanmy@google.com>,
	Emily Shaffer <emilyshaffer@google.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks
Date: Sat, 19 Jun 2021 03:58:57 -0400	[thread overview]
Message-ID: <CAOjrSZtKxEbMEbNZ+KEDfoJSOBSyKPY+PQRaP9sb7xgXiEFJZg@mail.gmail.com> (raw)
In-Reply-To: <020d01d76491$dcfe7c60$96fb7520$@nexbridge.com>

On Sat, Jun 19, 2021 at 3:32 AM Randall S. Becker
<rsbecker@nexbridge.com> wrote:
>
> On June 18, 2021 5:59 PM, Jonathan Tan wrote:
> 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?
>

Related question, if a project had a collection of suggested hooks,
and a contributor wanted
to update them in relation to a new feature or code change, would they
then have to create two
separate patches/PRs?  That feels like it would decentralize discussions/review?

For example, if I maintained a project on GitHub and a contributor
wanted to add a clang-tidy
invocation as a suggested hook, as well as a config file for it.  What
would the suggested workflow be?

"Open 2 Pull Requests one that updates both branches and do reviews
independently"?

If it was a mailing list would I have to send two separate patches?

I'm not familiar with any workflows or tools that allow you to review
and accept changes to
two branches as part of the same series of changes.

I also think that the history wouldn't be very clear in this case,
since there won't be any obvious
connection between updates to the suggested-hooks and updates to the
rest of the history in
this case (other than timestamps I guess, but I think that's a
relatively weak form of association)

> It seems like changes to hooks have to be managed in a similar way to standard managed files rather than as exceptions.
>
> -Randall
>


Thanks,
Matthew Rogers

  reply	other threads:[~2021-06-19  7:59 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
2021-06-19  7:58       ` Matt Rogers [this message]
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=CAOjrSZtKxEbMEbNZ+KEDfoJSOBSyKPY+PQRaP9sb7xgXiEFJZg@mail.gmail.com \
    --to=mattr94@gmail.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).