Well, that’s only if you never use git with a .mailmap.
The way I use git for my projects, I always just put a bogus email address into commits so it will never be current one day and then outdated another day. Then I put my “real” email address in the .mailmap.
So if I wanted to connect my git identities to the fediverse, I would have a couple options:
- start consistently entering in my git identity as
valenoern@codeberg.orgor something directly based on a fediverse instance - using some weird improved counterpart of
.mailmap, connect whatever git identities I’m using locally (those might look likevalenoern@pinebook,valenoern@server, etc) into a particular fediverse identity likevalenoern@codeberg.org
I may be misunderstanding what the problem is here, but if we assumed codeberg.org collected user email addresses during registration and could forward emails to its users if absolutely necessary, then wouldn’t fediverse handles on it like valenoern@codeberg.org become about the same as a ‘real’ email address for the purposes of git?
The process of emailing patches might even be a bit improved, because you could email a patch to valenoern@codeberg.org out of git and have it show up as a pull request in my inbox.
(Hopefully with the patch file annotated with what project it’s for so it would be grouped with the correct project. Maybe the most simple and future-proof way would be something like, you email to valenoern+bopwiki@codeberg.org to send a pull request for Valenoern/bopwiki?)
Or, who knows, maybe upgrading the emailing capabilities gitea servers already have would be too much and we’d be extending git to be able to directly send ActivityPub.
I guess it depends on whether we’re counting on most contributors being able to install things like git, or assuming entire software communities are going to shift further toward platform computing where codeberg.org does all the technical work for a big category of completely “non-technical” users that just sign on and advise all the platforms they use on what direction they should go.
(I have my own biases against some forms of platform computing, but I also don’t want to make the assumption it couldn’t lead to interesting new forms of governance where, say, a bunch of non-programmers elect a new leader to a stagnating project that keeps wilfully ignoring issues, and this eventually leads to a real plan to get them fixed.)