On Tue, Jan 28, 2020 at 4:36 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Sun, Jan 19, 2020 at 7:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Ah, that makes sense. Although Mark's idea of including a library
> > of possible hooks somewhere under src/tools/ seems even better.
>
> +1. And directions for setting them up (or, as I think he was
> proposing, a script, but directions might be better).
>
> > Another point is that a server-side hook is really too late: you'd
> > rather get the notice before you "git push", not after.
>
> Yeah, getting warned at commit time would be good.
For warnings, the server-side hook is definitely too late -- as those
are things end up being accepted anyway, and since it's git you cannot
amend them after you've pushed (cleanly).
Server side hooks are appropriate for things that should be outright
refused (like we for example refuse pushes from committers who have
misconfigured their git client -- it has happened a few times that
we've rejected pushes with commits from user@localhost or similar
instead of their registered email address). In those cases the commit
is completely rejected with an error, not a warning, so there's a big
difference.
> Another thing that would be nice is to warn about commits that don't
> include a "Description:" line. I have been trying to be religious
> about that, but I seem to periodically apostatize.
We'd also have to come to this magic actual agreement on which such
fields we *want* :) Which alone would be an improvement.
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
