This feels like you just swapped the identity management problem, and turned it into a key management problem which is in no way better.
I feel like just having some opaque ID for the committer and then having some mapping that isn't tied in the merkle tree would solve the problem for every case described here, without involving any extra network services, cryptography or whatever. Only downside is that it doesn't work with commit signing, but who does that anyway?
Funny that in the context of the repositories, Monotone's data model would make this all basically a non-issue (although server admin would need to remove the old commit-author records, but it won't change anything about commits themselves as referenceable parts of content history, and the new commit-author records signed by the same key as the old one won't even look out of place).
Hmm, how do Git notes handle force-push to the notes-carrying hidden branch?
oliverpool | 20 hours ago
If a private key is needed to perform git operations, then https://radicle.dev isn't far, no ?
ignaloidas | 13 hours ago
This feels like you just swapped the identity management problem, and turned it into a key management problem which is in no way better.
I feel like just having some opaque ID for the committer and then having some mapping that isn't tied in the merkle tree would solve the problem for every case described here, without involving any extra network services, cryptography or whatever. Only downside is that it doesn't work with commit signing, but who does that anyway?
k749gtnc9l3w | 19 hours ago
Funny that in the context of the repositories, Monotone's data model would make this all basically a non-issue (although server admin would need to remove the old commit-author records, but it won't change anything about commits themselves as referenceable parts of content history, and the new commit-author records signed by the same key as the old one won't even look out of place).
Hmm, how do Git notes handle force-push to the notes-carrying hidden branch?