Re: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks
- From
Matt Rogers <mattr94@gmail.com>
- Date
- Jun 19, 2021, 07:58 UTC
- Message-ID
- <CAOjrSZtKxEbMEbNZ+KEDfoJSOBSyKPY+PQRaP9sb7xgXiEFJZg@mail.gmail.com>
- 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