Eh, in a myopic sense yes, but folks are using Microsoft GitHub for their CI, issue tracker, forums, kanban, Wiki & so forth. By choosing their Markdown fork, you are locked into that too. Some communities like Elm, Unison, Nix use MS GitHub as your primary community identifier (Elm doesn’t even allow you to create packages on another platform). Many tools only allow MS GitHub single sign on. If you fork off of MS GitHub, in most scenarios you’ll still be required to have an MS GitHub mirror or you won’t be able to submit a pull request as most projects don’t have an alternative contribution channel.

Some of this can be migrated, some of it can’t & the whole time being entrenched in MS GitHub land projects will fear friction & loss of users/contributors if they move (& the platform they would move to likely isn’t offerering anything more than being open source).

So can you just move the code elsewhere since Git is a DVCS? Yep. But projects are more than just the source code.

Agreed. That said, with a few remotes and a cron job git could facilitate “duct tape and zip ties” federation.

I love a friendly debate 😀:

The statement says How can you steal something that the customer cannot own?. You can definitely steal it if “you” aren’t the customer. And you can steal it from a “customer” even if the customer doesn’t own it and someone else does. And you can steal if even if you are the customer, because you aren’t the owner. The only time you can’t steal it is if you are the owner, because you own it.

The definition of “steal” you mention seems to be proving the point I’m making. Something can be stolen if the person stealing is isn’t the owner, which is the case in all of the ones I mentioned above.

The statement is a weird play on words and loaded with assumptions that are left up to the reader, which is why it’s super weird to use it to try to prove the point the author was trying to make.

There isn’t anything I see either. The only reference is being built similar to Bitcoin’s Lightning network (while also say it is inspired by Secure Scuttlebutt & BitTorrent (hence “seeding” a repo)). It doesn’t solve my issues in the space, but it is at least trying something novel.

Personally, I find the Patch Theory options the most compelling since fundamentally patches should commute—weaning it doesn’t matter if patch α or patch β was merged first & you start to feel weird that you get merge conflicts despite the same end result in something snapshot-based. The two big contenders are Darcs, the still-maintained pioneer in the space & new(ish)comer, Pijul. Darcs has less rough edges being about as old, stamse as Git but has some performance issues (where some of the old perf issues are fixed, some remain) & being Haskell, libraries get created since that community loves to code more than it likes to maintain so libraries can go out of date & package tooling still isn’t what it could be. Pijul, memes aside, is written in Rust with some more modern sensibilities & a really cool idendependity identity management system (you can hide your name/email for privacy, or change it to not be deadnamed & not have to raise a merge request to rebase you identity on all repos you contributed), but it’s pretty barebones despite being technically feature complete I believe—with rebase being missing feels like a glaring issue as the way to fix patches isn’t fully exposed. Nest, the forge of the creator, is pretty lackluster too IMO from featureset to self-hosting stack without any real alternative yet. It’s still a project worth watching & SSH+HTTPS work fine for hobby projects. Darcsden is fine but not great, but newly started Smeederee seems to be going in a good direction, the rest of the forges are written in like Python 2. …Which is the part where I would like to see some of that yet-another-Git-forge effort flow into these channels.

Fossil is interesting too for shipping the whole forge, & have heard great for small teams as that is what is optimized for, but I haven’t used it.

That’s how a “hot take” should work

Yeah, I stand by my stance that Microsoft has poisoned the whole Git experience, where everyone will be comparing all forges to MS GitHub & the direction of the Git project ship is being steered heavily by Microfsoft. I also disagree with “best” VCS–I will agree with Git the most tooling around it which can lead to a better overall experience, but Git’s fundamentals are not without some obvious flaws.

Then you are suggesting “the people” can take Git back from that narrative–because you can’t deny that the majority of projects are on Microsoft’s platform. Maybe they can, & I hope they can too! …But I am skeptical that any true migration will actually be done before there is a tool adopted anyhow, so I would prefer we accelerate the adoption of that new tool+platform instead since I think there are some underrated tools that folks are missing as they have never even looked outside the Git bubble. I migrated everything I could off in 2016 with the Microsoft purchase, & so many folks said they would too. It’s been 8 years, & even with some folks going elsewhere, more new folks are replacing them on MS GitHub than there are those leaving (thanks education system).

My memory could be failing me but I believe the gaming industry prefers Perforce for large files. Pijul’s FAQs seems to point in the direction that it could be good enough for some use cases. I haven’t put too much effort into researching solving that specific hard problem, but if I was to create a video game, you really need to look at how to best handle your assets.