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

From: Jonathan Tan <jonathantanmy@google.com>
To: mattr94@gmail.com
Cc: rsbecker@nexbridge.com, jonathantanmy@google.com,
	emilyshaffer@google.com, git@vger.kernel.org
Subject: Re: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks
Date: Mon, 21 Jun 2021 11:37:22 -0700	[thread overview]
Message-ID: <20210621183722.1167322-1-jonathantanmy@google.com> (raw)
In-Reply-To: <CAOjrSZtKxEbMEbNZ+KEDfoJSOBSyKPY+PQRaP9sb7xgXiEFJZg@mail.gmail.com>

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

With the current design, the answer is "yes" to both. Having said that,
for this particular case, I think that the clang-tidy config file can be
reviewed and merged first, and then the clang-tidy hook. (The hook needs
to be written to also work in the absence of the config file, since the
user may have checked out an older version, so as far as I can tell,
there is no need for precise timing as to when the hook is merged.)