CVS used to be the standard before Git. Arguably CVS as the standard was not better than no standard if no standard let you use decentralized version control.
But Git is pretty good, so it will take something vastly better to replace it.
But Git is pretty good, so it will take something vastly better to replace it.
I don't believe any version control system achieved as deep industry penetration as git has.
There were of course places that were late to switch. I remember one of my old work places used P4 due to legacy in the CI/CD pipelines, but many teams kept a "shadow" git repository in Bitbucket with a bridge to P4. After a while, the company finally switched to Github Enterprise
It definitely wasn't everywhere 10 years ago (but github was). Do you mean 15-20?
Regardless, having completed a CS degree during the period SVN was supposedly everywhere and only encountered it once because someone in my capstone team knew how to use it, I'm inclined to think it didn't permeate everything the way git does now.
If I could complete a bachelors in CS without encountering it in any of my courses, I think it's safe to say git is much more ingrained in the field now (pretty much every syllabus I come across online for CS courses from the last 5 years has had some github links)
Perhaps, but I've never seen that done. The version control system that is in fashion changes over time, but for my entire multidecade career there has always been one.
Personally, a guy I dealt with circa 2010 stood up in a meeting on building better site-wide development processes, and asked what the point of version control was.
So, you've been lucky.
Now, if you go back to the mid '80s and earlier, version control was rare.
yes ... how did you know we used visual source safe?
Yes, we had MS support, and they looked into it, and eventually basically shrugged (I'm told. I wasn't the one working with them).
I'd say each predecessor had about the same level of penetration, which was 'nearly all'. CVS->SVN-GIT. Git will be replaced. It's ripe for that - its interface is terrible, storage is now cheap, and many companies have no actual need for decentralized version control and the complexity that comes with it.
Easiest to use of the bunch is still svn. You can teach a developer everything they need to know in 5 minutes and there's 3-5 commands total you'll need to use ever. I never once saw anyone get into some nightmare state they needed help to dig out of like I've seen routinely with git.
Git is fine, but honestly, my favorite of the several I've used over the years is still svn.
Edit: And Visual Source Safe
I preferred just a normal folder, rsync (or some nt utils equivalent) and backups.
As I recall, the main problem was that VSS didn't have a proper server! Instead the client modified files in the repository directly using Window's file sharing, relying on locks to maintain consistency. This would have been a bad idea even in Window's file shares weren't slow and buggy.
If everyone develops from master branch and makes small incremental changes, no problem even if it's git.
If everyone develops from their own branches and goes off and does their own thing for a month, but those things are all in totally separate areas of the codebase, not as much of a problem either.
If everyone is developing in their own branches for a month, and they're working on overlapping things, and they aren't communicating? Then you get merge problems
But it's not really a merge problem, it's a communication problem. (And it's not git-only, you see merge problems even in perforce when people go dark for a long time and come back with a huge change that's got conflicts on 50% of the lines now)
I've seen other systems essentially say, "Oops both versions modified this file... Good luck!" It didn't matter that the modifications were to very different parts of the file. I've never seen that in Git. Any merge conflict I've gotten in Git has been a true potential conflict, even if the resolution is straight-forward from my perspective.
A 3 way merge would have "original", "version a", "version b", and "version c", where "original" is the common ancestor of a, b and c. Mercurial disallows merges like this, but git supports them. I have no idea why git allows it.
But yes, older VCSs ignored the "original" concept, which meant diff tools could just pop up "a" and "b". Which is just a way worse idea than including the original as well.
As for dealing with merge conflicts, it's called
- keep up to date with the branch your tracking
- merge frequently
- get on a call when you do have merge conflicts
- avoid having multiple people working in the same files simultaneously if possible
That sounds like a lot of words for "try really hard to avoid having merge conflicts, because they suck to deal with"
I was using ClearCase for a few years and they had a really nice visual merge tool, but the complexity of the merge was great because they were so infrequent. I made a mistake and let someone find out I could merge and ended up getting sucked into these quarterly multi-day merge sessions that made me feel like a guild navigator stressing about breaking one of thousands of changes from 50 people over 90 days.
The patch-centric model of Darcs and Pijul is insufficient. You also need to remember where patches came from. If rewriting a patch does not keep its provenance, you're also in for a world of hurt.
But even that is not sufficient. You need to have more context than even the patch-centric model gives you.
Correction: Git is super mediocre, but sufficiently wide spread it will take something vastly better to replace it.
Don’t confuse inertia with goodness.
Are you saying that the CLI is bad, or that Git’s underlying concepts and data model are bad?
I think the plumbing is probably in-between poor and bad for most projects. It’s maybe great for Linux. However almost all projects are effectively centralized so the D in DVCS is a waste. (Offline/local support and fully distributed are different). I think source control should make it impossible for 99% of users to shoot themselves in the foot. And Git is still terrible at large binary assets, even with Git-LFS.
I use Git + GitHub for my personal projects. It’s mediocre but tolerable. Git is insufficient and not used for every professional project I have ever worked on. YMMV.
What VCS would you use if it was all up to you?
Almost 100% of game devs use Perforce. Git is a non-option.
BigTech all use highly custom source control systems. They have some nice properties.
My stance isn’t that we should use something other than Git per se. It’s that Git is a local maxima, and it kinda sucks. And I think the industry would be healthier if people agreed Git sucks.
Features I care about:
* Terabyte scale sparse checkouts * Ten terabyte scale full checkout * Petabyte scale history * Lossless history. * Automatic cloud/remote backups of every commit * Trivial for low-tech people to use (Perforce achieves this) * Cross-branch file locking for non-mergeable assets
Things I don’t care about:
* Distributed. Defacto centralized with forking is all I need. * Rewriting history. Linux needs it, I don’t.
There are of course lots of things I do like about Git. It’d be good if Git and Perforce had some competition. There’s a market opportunity for it imho.