It still blows my mind how git has lost it's original ideas of decentralized development because of github and how github, a for-profit - centralized - close-sourced forge, became the center for lots of important open source projects. We need radicle, forgejo, gitea to catch up even more!
It didn't really lose the original ideas. It just never learned that people don't want to use it the way kernel devs want to use it. Git never provided an easy github-like experience, so GitHub took over. Turns out devs in general are not into the "setup completely independent public mailing lists for projects" idea.
> Turns out devs in general are not into the "setup completely independent public mailing lists for projects" idea.
My feeling is that devs in general are not into the "learning how to use tools" idea.
They don't want to learn the git basics, they don't want to learn the cmake basics, ...
I mean that as an observation more than a criticism. But to me, the fact that git was designed for those who want to learn powerful tools is a feature. Those who don't can use Microsoft. It all works in the end.
Fun fact: if I want to open source my code but not get contributions (or rather feature requests by people who probably won't ever contribute), I put my git repo on anything that is not GitHub. It feels like most professional devs don't know how to handle anything that is not on GitHub :-). Bonus point for SourceHut: if someone manages to send a proper patch on the mailing list, it usually means that they know what they are doing.
> My feeling is that devs in general are not into the "learning how to use tools" idea
Well, the devs learnt how to use Github, didn't they? Seems like people CAN learn things that are useful. I can also make the argument that Github pull requests are actually more powerful than git request-pull in addition to having a nicer UI/UX.
Being upset that people aren't using git request-pull is like the creator of Brainfuck being upset that scientists aren't using Brainfuck instead of something more powerful and has a better UI/UX like Python. It's kinda obvious which one is better to use...
> My feeling is that devs in general are not into the "learning how to use tools" idea.
Given the number of vim, emacs, nix, git, i3, etc. users who are proud of it and all the customisations they do, I don't think so. Like, there will be a decent group, but not generalisable to "devs".
I once worked at a smaller company that didn't want to shell out for github and we just hosted repos on some VM and used the ssh method. It worked. I just found it to be kind of clunky having come from a bigger place that was doing enterprise source control management with Perforce of all things. Github as a product was fairly new back then, but everyone was trying to switch over to Git for resume reasons there. So then I go to this smaller place using git in the classic manner.
For me the largest advantage of Git was being able to easily switch branches. Previously I'd have to have multiple copies of an entire source repo on my machine if I wanted to work on multiple things at the same time. Likewise a patch set going through CR meant an entire folder on my machine was frozen until I got feed back.
Not having to email complex patches was another huge plus. I was at Microsoft at the time and they had home made scripts (probably Perl or VBS, but I forget what) that applied patches to a repo.
It sucked.
Git branch alone was worth the cost of changing over.
I don’t think it’s really that surprising. git didn’t become popular because it was decentralised, it just happened to be. So it stands to reason that part doesn’t get emphasised a ton.
It did become popular because it was decentralized, but the specific features that this enabled were less about not depending on a central server, and more about being able to work with the same repo locally with ease without having to be online for most operations (as was the case with Subversion etc). Git lets me have a complete local copy of the source with all the history, branches etc in it, so anything that doesn't require looking at the issues can be done offline if you did a sync recently.
The other big point was local branches. Before DVCS, the concept of a "local branch" was generally not a thing. But now you could suddenly create a branch for each separate issue and easily switch between them while isolating unrelated changes.
