Conversation

Notices

1. Embed this notice
   David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)'s status on Friday, 05-Dec-2025 22:36:20 JST David Chisnall (*Now with 50% more sarcasm!*)

   Git's Signed-off-by: is such a ludicrous thing, made even more ludicrous by people who have checks that the author of a commit has the same email as the person who signed off.

   I would be shocked if a court decided it matched the legal requirements for a binding contract in any context where the git commit itself did not. Checking that two fields match, when you have no way of validating that the person who created the commit is actually the person identified by either is a complete waste of time.

   And it also incurs some fun GDPR liability. Now you have an email address in the commit message, as well as the author metadata. How do you comply with a legal requirement to remove personal information from your history?

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Friday, 05-Dec-2025 22:36:20 JST ✧✦Catherine✦✧

     in reply to

     @david_chisnall this all seems right but isn't normal Git already a GDPR nightmare? (my understanding is that the way to deal with this is to claim an exemption due to technical impossibility, but IANAL)

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Friday, 05-Dec-2025 22:47:58 JST ✧✦Catherine✦✧

     in reply to

     @david_chisnall Oh, that sounds like a proper mess.

     I have, most likely, dozens of git repositories with a name I'm no longer using, so the thought of git-filter-branch crossed my mind, but I've eventually concluded that:
     - it will be extremely disruptive to any actual users
     - it will call extra attention to something I'm leaving behind

     ... but that's specific to me. In general I think a VCS should support name changes. I'm not sure how, though.

   • Embed this notice
     David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)'s status on Friday, 05-Dec-2025 22:47:59 JST David Chisnall (*Now with 50% more sarcasm!*)

     in reply to

     • ✧✦Catherine✦✧

     @whitequark

     As always happens when I speak to multiple lawyers, I get multiple answers. The opinions are either:

     • You should rewrite history to change the author info to some tombstone (and, yes, mess up everyone's downstream forks, though you can add fake parents to each new commit to make merges work).
     • You can argue that the history is a functional requirement and fall back to legitimate interest things.

     There are now some tools to do the former, so it's less likely that the latter would convince a court. But now you've added more complexity because you have to change things in commit messages as well as the author field.

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Friday, 05-Dec-2025 22:49:21 JST ✧✦Catherine✦✧

     in reply to

     @david_chisnall I think you could store the UUID => name/email map in a "sidecar" that is updated destructively while the main Merkle tree remains intact?

   • Embed this notice
     ✧✦Catherine✦✧ (whitequark@mastodon.social)'s status on Saturday, 06-Dec-2025 00:02:33 JST ✧✦Catherine✦✧

     in reply to

     • jaseg

     @david_chisnall @jaseg I was thinking of this too! it's cursed but broadly compatible at least

   • Embed this notice
     David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)'s status on Saturday, 06-Dec-2025 00:02:34 JST David Chisnall (*Now with 50% more sarcasm!*)

     in reply to

     • ✧✦Catherine✦✧
     • jaseg

     @jaseg @whitequark

     Yup, that's a good equivalent. I wonder if you could encode these things as tags. Tags currently refer to a single commit, but I guess you could have a namespace of tags for commits from a specific person and one tag for each commit that they'd made. Or you could add some proper indirection and have the author refer to a tag name and the tag name just point to a single object that contains the real name (rather than a commit in the history).

   • Embed this notice
     David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)'s status on Saturday, 06-Dec-2025 00:02:36 JST David Chisnall (*Now with 50% more sarcasm!*)

     in reply to

     • ✧✦Catherine✦✧
     • jaseg

     @jaseg @whitequark

     Yup, that's the key difference with the Pijul approach. The mapping is part of the repo state, but not part of the history. Git doesn't have any similar abstraction for building this kind of thing, as far as I am aware, except maybe git config (but I don't think you have a way of querying a remote's config?).

   • Embed this notice
     jaseg (jaseg@chaos.social)'s status on Saturday, 06-Dec-2025 00:02:36 JST jaseg

     in reply to

     • ✧✦Catherine✦✧

     @david_chisnall @whitequark branch names and tags work kind of in a similar way, they are synchronized as needed, things work without them, and they are not part of the history.

   • Embed this notice
     jaseg (jaseg@chaos.social)'s status on Saturday, 06-Dec-2025 00:02:37 JST jaseg

     in reply to

     • ✧✦Catherine✦✧

     @david_chisnall @whitequark you could even stay backwards compatible by adopting some well-known syntax to put into the author fields that points to the in-tree author aliases file.

     This likely wouldn’t completely solve the GDPR issue since you would still be able to access old versions of that author name mapping file, but you could even work around that by doing sparse checkouts and only keeping the latest version of that file.

   • Embed this notice
     David Chisnall (*Now with 50% more sarcasm!*) (david_chisnall@infosec.exchange)'s status on Saturday, 06-Dec-2025 00:02:39 JST David Chisnall (*Now with 50% more sarcasm!*)

     in reply to

     • ✧✦Catherine✦✧

     @whitequark

     Pijul does, in the traditional computer science way: Names in the commit history are unique opaque identifiers. The repository contains a mapping from those to people, but that mapping can be changed (and can be different on different repos). If I remember correctly, they have a little bit of public-key crypto to make sure that the same identifier in two repos is the same person, but that doesn't let you know which person without the other metadata.

   • Embed this notice
     jaseg (jaseg@chaos.social)'s status on Saturday, 06-Dec-2025 00:02:39 JST jaseg

     in reply to

     • ✧✦Catherine✦✧

     @david_chisnall @whitequark If you’d implement this in git, it wouldn’t even be the first use of in-tree metadata (see .gitmodules) and it also wouldn’t be the first instance where the output of git log etc. could change after the fact without rewriting history (see branch names). maybe this would actually be worth an RFC in case this hasn’t been proposed before.