You want to:
1. Rewrite git history — ask Savannah admins to force-push master to
scrub a Co-Authored-By line.
2. Revert and re-apply — same commit, different message, as a
"compromise."
3. Add a git hook — to police commit messages for LLM attribution
strings.
Such a nitpicking. All over a single truthful trailer line. The code is
reviewed, and the author has FSF papers, the attribution is honest, no
legal issue yet it becomes procedural theater.
On 2026-07-25 23:27, Jim Porter wrote:
Thanks Sean, Eli, and Yuan for resolving this all amicably. I'm happy
to see that this was simply an honest mistake. And thanks to Divya for
alerting the mailing list.
On 7/25/2026 12:21 PM, Sean Whitton wrote:
Eli, what do you think we should do? Should we ask the Savannah
admins
to help us forcefully undo this commit, or is it enough just to
replace
the entry in the ChangeLog file exported after cutting the emacs-32
release branch?
I think the commit message saying co-authored by Claude even though
the
code in the commit was not co-authored by the LLM is a problem because
we have no way of telling people that, in fact, this commit is not
LLM-authored. So I worry that people will keep finding it and then
coming to the list to ask about it. So I think that we should
consider
asking the Savannah admins for help.
I agree. Given the legal concerns (not to mention other ethical
problems the FSF may want to take a stance on), it would be best to
take some action now to clarify things so that we don't forget what
happened if/when LLM contributions become a more pressing issue.
Since this is a recent change and so far a unique case, I like the idea
of asking the Savannah admins to help rewrite Git history to set the
record straight. If that's too invasive and people object to it, as a
compromise we could revert the commit and re-apply it with the fixed
commit message. Git history would still show an LLM-encumbered commit,
but the reversion would keep it out of Git blame and help to explain
matters to anyone who looks at our Git logs. (I don't think simply
amending the ChangeLog is enough, since any future people auditing the
code will likely look at Git to make sure they see *all* the commits.)
Going forward, what do people think about adding a Git commit message
hook to check for this? That way, we can catch honest mistakes and
remind the committer of our policies. (To preempt the obvious response:
people could of course lie about whether they used LLMs, but we already
place a lot of trust in people with commit access, so I'm willing to
trust them on this as well. Anyone who knowingly broke our trust over
this or something else should probably lose commit access.)
If there's interest in a Git hook, I could make the necessary changes,
since I've already done some work on the Git hooks before.
--
Jean Louis
---
via emacs-tangents mailing list
(https://lists.gnu.org/mailman/listinfo/emacs-tangents)
