> Once better alternative emerges we'll jump the git ship as we did before when we jumped onto the git ship.
It's not that easy at this point in time. git carries a lot of momentum, especially in combination with GitHub.
Anybody learning about software development learns about git and GitHub.
Software is expected to be in GitHub.
At the time git became successful there were arguably better systems like mercurial and now we got fossil, but git's shortcomings are too little of a pain point compared to universal knowledge about it and integration into every tool (any editor, any CI system, any package manager, ...) and process.
>It's not that easy at this point in time. git carries a lot of momentum, especially in combination with GitHub.
CVS back then was like this too, including public repos, etc.
>At the time git became successful there were arguably better systems like mercurial
I specifically mentioned Mercurial above because they both emerged pretty simultaneously responding to the same challenges, and Mercurial happened to be just inferior due to its design choices. Companies were jumping onto it too, for example our management back then chose it, and it was a predictable huge pain in the neck, and some years down the road it was replaced with git.
> CVS back then was like this too, including public repos, etc.
Not really.
CVS had too many flaws (no atomicity, no proper branching, no good offline work, etc.) Subversion as "natural successor" fixed some things and was eating some parts of CVS.
At the same time sourceforge, the GitHub of that time, started to alienate their users.
And then enterprises used different tools to way larger degree (VSS, sccs, Bk, perforce, whatever) while that market basically doesn't exist anymore these days and git is ubiquitous.
And many people went way longer without any version control than today. Today kids learn git fundamentals very early, even on Windows and make it a habit. Where's in the early 2000s I saw many "professional" developers where the only versioning was the ".bak" or ".old" file or copies of the source directory.
People started paying me to develop software in 1986. First time I ever used version control software was 1996. It was TERRIBLE. Two years later I left to start my own software company, but my experience with it to that point was so bad I went without version control the first few years. Around 2002 I started using CVS (or RCS? long time ago!) and quickly switched to Subversion. After learning git to work on Raku circa 2009, I switched my main $WORK repo to git in maybe 2012. Every repo I've created since then has been in git, but I still haven't moved all my svn repos over to git.
It's not that easy at this point in time. git carries a lot of momentum, especially in combination with GitHub.
Anybody learning about software development learns about git and GitHub.
Software is expected to be in GitHub.
At the time git became successful there were arguably better systems like mercurial and now we got fossil, but git's shortcomings are too little of a pain point compared to universal knowledge about it and integration into every tool (any editor, any CI system, any package manager, ...) and process.