forge "fragmentation" is a good thing. git was meant to be decentralized from the start. re-centralizing on a single provider would just repeat the github saga all over again.
it is good if people actually develop good workflows. Actually in applied research/public gov tech we are seeing tons of different gitlab instances.
One project we are contributingto the Fraunhofer team developing it has had an internal gitlab with CI/CD and mirrors at three different sites: gitlab.com, opencode.de and code.europa.eu . Now they are slowly trying to move to gitlab.com for the main repo as they cannot open their own repo enough for security/legal reasons. However, the CI/CD stuff still only runs on their gitlab.
Now we have our own gitlab instance we, were we are doing some small frontend work as part of a funded project on national level and have a mirror on GitHub for visibility reasons. Now we have another EU funded project that has its CI/CD on another gitlab instance at a partner. All come with their own onboarding and federated IDM quirks.
It is a total mess. While git is certainly distributed, the workflow is a mess. You end up cherrypicking CI/CD configs and divergent features all over the place.
I wonder: Is there a l'meta-forge' that just would handle rebasing?
I actually understand people using bare git workflow with mailing lists. However, even for me the learning curve and necessary attention span/social contracts is too much a challenge.
I upvoted because i agree with the message. Although, it would be much better if we could just have a single identity over those providers, just like we had with mailing lists.
i mean, in git (on its own) you can use your email + GPG key across every repo as a universal ID. it's just that forges add an identity layer on top, too.