Are you guys fine with these new shenanigans from Github. I found a bug and wanted to check what has been the development on that, only to find out most of the discussion was hidden by github and requesting me to sign-in to view it.
It threw me straight back to when Microsoft acquired Github and the discussions around the future of opensource on a microsoft owned infrastructure, now microsoft is exploiting free work from the community to train its AI, and building walls around its product, are open source contributors fine with that ?
Your project will inevitably get forked onto MS GitHub & the SEO will rank that fork above you—changing VCS adds a layer of friction that discourages forking back onto MS GitHub. Best you see is these pretty please attempts to encourage not forking to Microsoft’s platform. Microsoft has a massive pull in the direction Git goes, & whatever MS GitHub does, the alternative forges seems to want to clone their feature even if it’s bad (look at Forgejo diverging from Gitea to copy Actions verbatim even tho we all know working with YAML for CI is a bad idea that scales poorly).
And again, Git is not the best DVCS—but folks are hesitant to try other platforms since there is less forges & tooling. If Microsoft is controlling the Git ecosystem like it is, that effort, in my opinion, would be better spent choosing a better DVCS system that isn’t already infected by Microsoft or Google or Apple or similar.
I self-host GitBucket, and honestly your reasoning behind giving up arguably the best version control application, just because of one hosting site, is downright ludicrous.
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.
It hasn’t. There are literally thousands and thousands of developers using Git daily without having nothing to do with GitHub.
You are entitled to your opinion, but that’s a fact. What MS does or doesn’t, with GitHub, has no effect on these devs. You can see how egregious it is to read a random person sayint we should stop using a certain tool, because Walmart also uses it? Jeesh.
I would venture while thousands use Git without MS GitHub, 98% have an account since you largely can’t contribute to many projects without due to lock-in.
If Walmart was the biggest funder, making the most calls to the project, & optimizing it to be sold in their stores, I would 100% have hesitance against something if I could find an alternative (physical vs. digital goods working a bit different).
It’s not that I don’t see your point, it’s just that I’m pessimistic that the open source community at large would in practice move off of MS GitHub or otherwise offer alternative contribution channels before we would see another tool + platform supplant Git as the status quo in the next generation of VCSs. I would rather accelerate that future—unless like Google or Facebook is the clear leader of that new tool, but many projects right now not named Jujutsu seem to be independent.
The great majority of developers never contribute, that’s a false expectation. Majority of programmers work in the private sector and use local git hosts/solutions instead of GitHub.
Again, expecting those devs to not use git because of one hoster, is a ludicrous idea in itself.
Open source drives that ecosystem & the private sector follows suit as the developers try new tools & suggest platforms from their open source experience. There are a lot of companies on MS GitHub Enterprise as well as opening some of there source in the form of libraries & they all choose Microsoft for marketing reasons over technical ones (Git is just Git after all).
You are acting like I’m saying “leave Git now or else”. I suggest it could be an option, if IMO a faster option, to get out Microsoft’s of monopoly. It’s easier to pitch as better tool with better features that solve problems than argue “well, ethically, you just self-host or move to Codeberg since user freedom matters”. That philosophical argument is harder to preach than Fossil ports the whole forge + tooling ecosystem with your project or Darcs/Pijul solve the merge conflict order of patches not commuting or Mercurial offers a more user-friend CLI.
I don’t agree, but it’s a unique, interesting thought that I can upvote.
That’s how a “hot take” should work
What would you suggest is a better DVCS than git?
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
rebasebeing missing feels like a glaring issue as the way to fix patches isn’t fully exposed. Nest, the forge from Pijul’s 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. For Darcs, Darcsden is fine but not great & showing its age, but newly started Smeederee seems to be going in a good direction, the rest of the old 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 & enegery flow into these channels.Fossil is interesting too for shipping the whole forge, & have heard great for small teams as that is what it’s optimized for, but I haven’t used it.
If Darcs has performance issues, how is it better than git?
In many scenarios you probably won’t notice… but also Pijul has ‘fixed’ that fundamental perfomance issue. The Patch Theory states that patches, without depending patches that would cause a conflict, should commute—i.e. patch α + patch β ≡ patch β + patch α in the same way 1 + 4 ≡ 4 + 1 (order does not matter, output is equivalent). What this eliminates is an entire class of merge conflicts & opens up new ways to handle diffing. This particular class of conflicts makes it easier to work in a distributed project as anyone can pull in anyone else’s patch at different times in project without conflicts. In practice with Git being snapshot-based & patch order mattering, this tends to cause folks to rely on a centralized, canonical Git server to merge into to be able to ask what the order should be so everyone doesn’t get stuck in their rebases/pulls (
rererefails a lot).It turns out there is more to version control than how fast CPU go; if we measured programming languages with the same stick, we’d all only write assembly since everything else has a performance penalty.
The way you write about this seems very evangelical.
I use git every day and I don’t recall patch ordering ever being a problem.
Evangelical in that it’s documented an a theory & a paper for the concepts you can read about? Communicative properties are common in math–what’s novel is applying those properties to patches for source control compared to the older models.
Have you worked in a distributed team sharing just patches over email? If Alice pulls from Bob & then Catherine, but David reads & applies Catherine’s then Bob’s, Alice & David now have a conflict in the ordering when trying to push/pull later. I have ran into this. Or did you use a centralized, canonical (therefore not distributed) Git server with a pull request model? If you do the latter, you won’t run into the issue but you also aren’t using the distributed part of a distributed version control system (DVCS)–& most don’t since has too many issues with snapshot-based tools. This restricts the sorts of systems & team structures for source control we can even do (you need a Tvoralds dictator even for Linux’s mailing list) & we can’t really think outside the snapshot-limitations until we step outside of that snapshot bubble.
No, evangelical as in needing to tell people about it, even when they have no interest.
No.
Pijul is a very exciting project. I’ve wanted to try it for months buy haven’t found the time.
Not to say don’t (do try it), but Darcs might be better if you just want to understand some of the fundamentals since it’s more mature. A small project will not perceive any performance difference. If you use Git’s CLI heavily, Pijul’s CLI will seem barren in comparison & tooling even like vim-signify doesn’t have support. Pijul’s
diffisn’t GNUdiffcompatible so that tooling won’t help either.If you grasp Darcs, moving to Pijul is pretty simple since they are based on the same theory—you just might need to be invested enough to start building your own tooling which is more of a time commitment. Pijul is meant to be scripted which is partly why it’s barren—so for a trivial expample I created a small shell script
pijul-amendwhich wrapspijul record --amendwhich is picked up aspijul amendmimickingdarcs amend. Maintenance is easier when a project supports only the minimum set of commands, but you’ll be building your own ergonomics (no rebase, no send-mail, etc.). Maybe in the future when there is a bigger contrib space to fill in the gaps, it won’t be such an investment to just to test out.