bug#81520: Add pre-receive hook to Savannah to reject LLM-encumbered commits

Eli Zaretskii <[email protected]> Fri, 31 Jul 2026 13:51:18 +0300
Newsgroups gmane.emacs.bugs
Message-ID <[email protected]>
> From: Sean Whitton <[email protected]>
> Cc: [email protected]
> Date: Fri, 31 Jul 2026 11:04:51 +0100
> 
> > Pre-push hooks are an annoyance, because usually a push is supposed to
> > be a step that almost always succeeds.  Going back to commits and
> > redoing them is a terrible nuisance.  Moreover, in many cases I push
> > more than one commit, in which case rejection of one that is not the
> > last one is an even larger nuisance.
> >
> >> 2. LLM agents tend to try all possibilities - even bad ones[1] - to
> >> resolve failed commands. If we checked this in the commit-msg hook, an
> >> LLM that vibecoded a patch might well see the error from the hook and
> >> "fix" the problem by simply deleting the attribution, even without the
> >> user being aware.
> >
> > You seem to think about an LLM agent pushing commits?  How is that
> > possible if the agent doesn't have write access?
> 
> I understand your point about not wanting to encode an ever-growing list
> of e-mail addresses, Eli, so let's think about alternatives.

One alternative would be to search the entire log message and
author/committer addresses for regular expressions matching
"Anthropic", "ChatGPT", "OpenAI" etc.  Regexps make it easier to adapt
to changes and unanticipated issues, and can be general enough to be
relatively insensitive to minor changes in email addresses.

Btw, we must spell out these restrictions in CONTRIBUTE.

> I think that Jim has a good point about commit-msg vs. pre-push:
> I would be concerned about the LLM just removing the attribution in
> order to avoid the effects of the hook.  Recent models are particularly
> notable for their persistence.  It's somewhat reminiscent of the
> make-more-paperclips-by-any-means thought experiments.

Sorry, I don't understand the scenario.  If the attribute is removed,
how could the hook that searches attributions work in the first place?

In any case, my point is that delaying the rejection until push time
is much worse than rejecting commits, for the reasons I tried to
explain.  If we must have a pre-push hook (which I'm not yet convinced
we do), then at least let's have both pre-commit and pre-push hooks.