On 2019-04-23 20:26:10 +0000 (+0000), Fox, Kevin M wrote: [...]
I usually prefer server side hooks as then I don't have to deploy all the developer tools all of the random repos I contribute to require all the time. If it can be made server side somehow, thats vastly easier to deal with by folks like me or other drive by contributors.
Server-side hooks are fine for rejecting a push (if somewhat inflexible and hard to manage across projects, and in most ways inferior to equivalent CI jobs), but you don't want them altering commits as that invalidates any commit signing (in the git commit -S/--gpg-sign sense, not the -s/--signoff sense) the original committer may have performed.
I'm thinking more along the line of, we have a bunch of gate blocking tests that ensure some amount of code quality going in. But what if we could take it to the next level and have those tests actually feed back quality enhancements too, not just saying no and without the developer to install extra tools? [...]
The suggestion to have automation push a revision to a patch you propose while it's still under review is an interesting one, though it does bear some resemblance to the server-side hooks problem. The commit which would be approved and merged at that point isn't identified as yours. Some attempt could be made to have the automation masquerade as your identity insofar as forging the committer details to match the prior patch, but it wouldn't be able to reproduce your cryptographic signature so *if* you're keen on OpenPGP-signing your commits, you'll lose that when the auto-revised version ends up merging instead of your original. -- Jeremy Stanley