I believe moving over to #Codeberg is a big improvement over relying on #GitHub (which, as #SourceForge once was, is the center of gravity for FOSS projects' development).
I closed all my repos on GH some years back. I kept one or two repos on #BitBucket for years, but they were basically dead. When BB rid itself of #Mercurial ( #hg ) and switched solely to #git, I took advantage of the opportunity to close my account there.
That said, large numbers of people moving en mass from GitHub to Codeberg would just move the problem to a different platform. The problem being people rely heavily on a centralized service.
As for GitHub, I still have my account, and with job-hunting, I really need to put something there. Seriously, I have had some places send rejection notices because they couldn't see any evidence (on GitHub) that I knew anything about the job. But I really only want GH to be a secondary mirror of a main repo hosted elsewhere.
I think y’all know I favor the #Fossil #SCM / #DVCS over #Git (though I’m giving #Mercurial ( #Hg ) another look as well. I’m resource-constrained as well as energy-limited, but I have been thinking of standing up a miniature software forge for !FNetworks projects and users, likely using Kallithea (which can use both Hg and Git) and also having some Fossil repos (but not as part of a forge).
@sir created this whole toolkit that supports both #git and #mercurial and provides most of the same functionality as services like Github, Gitlab, Gitea, etc. WITHOUT USING JAVASCRIPT.
You want public repositories? Sourcehut has it. Continuous integration? Wikis? Mailing lists? Patch submission by email? Gist/Pastebin? It's all there.
There's a hosted version at <https://sr.ht>, and you can self-host instead if you want.
♲ @JordiGH@mathstodon.xyz: «There is no theoretical reason you can’t maintain two histories—-e.g. when rebasing have a “rebase-merge” commit that has the hash of the other tree, and optionally keep that history around in the git repo. Then you could do a ‘git blame —orig’ or whatever to switch between immutable and cleaned up history.
No VCS I’m aware of supports this. But they COULD.»
Huh, Facebook vanished from #Mercurial development since sometime in October 2018. They're not in the mailing lists, the IRC channel, and they're certainly not sending patches anymore.
I wonder what's up? They've been threatening to fork off for a long while now. I bet they finally did it.
I, for one, am relieved to see them gone. They did some good stuff but they were also a little unpleasant to work with.
Huh, Facebook vanished from the #Mercurial development since sometime in October 2018. They're not in the mailing lists, the IRC channel, and they're certainly not sending patches anymore.
I wonder what's up? They've been threatening to fork off for a long while now. I bet they finally did it.
I, for one, am relieved to see them gone. They did some good stuff but they were also a little unpleasant to work with.
«There is no theoretical reason you can’t maintain two histories—-e.g. when rebasing have a “rebase-merge” commit that has the hash of the other tree, and optionally keep that history around in the git repo. Then you could do a ‘git blame —orig’ or whatever to switch between immutable and cleaned up history.
No VCS I’m aware of supports this. But they COULD.»
How many of you *don't* enjoy using #git or #mercurial or #svn or any kind of source control at all? I want to find people who just don't like it and wish there was a better way. I know you're out there!