> Date: Wed, 29 Jul 2026 09:15:40 +0300 > From: Jean Louis <[email protected]> > Cc: [email protected] > > The commit (3735384b193617a912fbf6d25844041ed288bf28) was indeed > completely erased from the master branch through a force push. That is > evidence that it was not perfectly logical to give it to Claude to > commit messages. Therefore, the defense that "Claude was only used for > the commit message" collapses under the weight of the actual response. > If that were true, the commit would have been reworded, not erased.
We will indeed install a modified version of that commit soon. So nothing is "not logical" and no defense "collapsed". It seems that now you are saying that what I wrote cannot be trusted, either. > Developers are famously lazy in the efficient sense. If you're already > in your terminal, with git commit -m right there, why would you > interrupt your flow to involve a third-party AI service for a trivial > message? Pushing commits to the Emacs repository requires a lot of attention and care, so an assumption of being "lazy" while doing it is unjustified, if not simply unfair. > The only logical answer is that author was already in the AI workflow > for the code itself, so getting a commit message was just an extra step > in that same session. By your logic, maybe. I believe Yuan more than I believe your unfounded insinuations, sorry. > For the defense to be true, Yuan Fu would have had to: > > 1. Write the code by hand (fine) > 2. Manually decide: "I will now use Claude exclusively for the commit > message" > 3. Go to Claude, get the message, copy it, give instructions > 4. Commit > > But why? What was the purpose? I explained why, but you reject or ignore the explanation, which is perfectly logical. > There is no productivity gain. No quality > gain (it's a short message). No learning gain. It's an unnecessary > detour that only makes sense if the AI was already involved in producing > the code. The _result_ is a relatively short message. The code changes themselves are not so short, so summarizing them in a short message might not be as trivial as you think for a non-native English speaker. > I love GNU and want it to remain free, which is exactly why I must point > out this flaw—not to attack, but to protect the project's integrity. Protecting GNU is our job, and we are very serious in doing it. --- via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)
