On Sat, Jun 19, 2021 at 3:32 AM Randall S. Becker
[off-list ref] 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