Re: LLM Commit in upstream `master`?!
<[email protected]> Sun, 26 Jul 2026 13:17:46 +0200
| Newsgroups | gmane.emacs.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sun, Jul 26, 2026 at 02:09:22PM +0300, Eli Zaretskii wrote: > > From: Sean Whitton <[email protected]> > > Cc: [email protected], [email protected], [email protected], > > [email protected] > > Date: Sun, 26 Jul 2026 11:42:57 +0100 > > > > Eli Zaretskii [26/Jul 7:56am +03] wrote: > > > > > We should remove the Co-Authered-By heading, but that can be done by > > > editing the generated ChangeLog. > > > [...] > > > We could do that, but forced commits are trouble for everyone, so we > > > should think hard whether this is justified. We have more grave > > > mistakes in commit messages, like the missing > > > Copyright-paperwork-exempt thingies (which _are_ legally significant), > > > but we never even bother fixing them. If the only problem is to cope > > > with people who ask questions about that, I'd say "bring them on". > > > > I am convinced it's justified in this case. We don't want people doing > > data mining or searches on the Git history of our project to think that > > the body of this commit was written by an LLM. > > Isn't that a lost battle? Nothing is ever lost on the Internet; in > particular, sites like the Way Back Machine will have picked up that > instance already, as well as whatever Git mirrors are there in the > wild which sync with us. I don't think a forced push can give us what > you'd like to have, not after more than a day this was in the wild. > > So I'd say let's revert the commit and reinstall it without the > Co-Authored-By header, and that should be enough. Here from the side-line: I think reverting and re-committing (with a descriptive message in the revert stating why) is by far the cleanest solution. Whoever does mining will see the revert (or they don't know what they're doing). Changing history is always messy if there are unspecified copies around. Cheers -- t
signature.asc
(application/pgp-signature, 195 B)
-----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCamXs0wAKCRAFyCz1etHa RhPbAJ4qOId1lxmv0H5r0mlfHgsknWdgpwCggau3Z1xgCxG1UdCAefDmtv7aMcA= =CghD -----END PGP SIGNATURE-----