It's overly complex, uses esoteric and inconsistent commands, and is generally unusable by mere mortals -- presenting a significant barrier to entry for the wrong types of people.
For mere mortals, git clone/pull/commit/push suffices 99% of the time. You can use git for years without needing to understand what's happening under the hood, resorting to Stack Overflow when you need to do a 1% operation.
How many other SCM tools have you used? In my experience git gets a fair deal of hate, but everyone switched over to it because 1) the alternatives are worse and 2) github revolutionized the way that we write and share software.
Before git, the most popular SCM tool was SVN, which required you to talk to a central server for everything you do (single point of failure, slower, no offline). I've used mercurial before too, and its approach to branching is pretty painful.
I've heard of some enterprise companies needing to use git alternatives for very specific needs or scalability issues, but outside of that IMO the only meaningful downside to git is that there's a learning curve to using it. But it's not much of one - once you understand the mental model and what the basic commands are doing, you can get by just fine. The average person doesn't need to know about git rerere or octopus merging.
(also, commits are effectively immutable for public projects, which sucks for trans engineers who change their name)
When Git was taking over from SVN, the main benefit I remember reading about was the much faster/lighter-weight branching. IIRC in SVN making a branch makes a complete copy of all the files. Since then it's benefited from being the standard everyone (kinda) knows despite its sharp edges.
I've never worked with anyone who publicly said they disliked git. Those who didn't understand it always preferred to use a GUI, such as Source Tree, Github, or VS Code.
Personally, whenever git was unable to do something I needed it to, I have always been able to add a git alias to my `.gitconfig` that became a new part of my workflow, essentially extending the CLI. I've found it to be easy to work with, and the amount of great tooling I've found built on top of it is amazing.
I've never used a version control system other than git though. So I am heavily biased. Before I was introduced to git, I didn't use version control at all, and so maybe it's a case of the grass is always greener. But I came from a place without any grass at all.
Late 2000s/Early 2010s there was greater variety in version control tooling. Distributed VCS was new. Mercurial promised to be the “easy” version. Subversion was still heavily used and maintained.
GitHub quickly established itself as THE place to share and collaborate code. To use it you had to learn git.
Most people, still, to this day have a fairly shallow understanding of git and find themselves encountering lots of foot guns, lack of opinions, and UI inconsistencies. I’m not sure without GitHub, git would be as dominant.
I have used git since the beginning, have worked on a very large mercurial project, and git was always better. Mercurial was very slow at the time and because it didn't have rebase, repo history got absolutely full up with merge commits. There was something called a patch queue that was like rebaseable pseudo-commits but it wasn't quite good enough.
git didn't solve this problem hard enough (it still has merge commits and honestly I would like to see a model that doesn't have them at all, however that would work) but at least it was fast.
Here's my mathematician's perspective on this, having used CVS, Darcs, and Mercurial a lot before Git. One day, angry by the situation with Bitkeeper, Linus Torvalds thought to himself "Let's pretend that Sha1 hash collisions don't happen; what can we do?". The result that he deduced from this assumption was a distributed revision control system that was an order of magnitude more efficient than any of the competition, and this was absolutely critical to its success. And Linus probably just assumed the Sha1 problem could be sorted out later (like it was [1]).
Similar story here, though I think we had the desire to move away from darcs too - because we were hitting the exponential-time problem with patch-replays.
Darcs was a nice system, but with the unfixed(?) massive slowdown it just wasn't workable. We toyed with mercurial, but settled on git within a year or so.
In my recollection, github got popular fast because git was already the cool hype VCS. The kernel guys were the real trendsetters. It seemed like everybody and their mother was giving or attenting git presentations at work, college, LUGs, etc. Github rode that wave of hype at just the right time.
I'd be fine with Git if it wasn't for every single GUI for it being a steaming pile of crap.
I use CLI for committing/pushing/branching etc... But anyone who pretends that CLI is adequate for inspecting history and changes or operations such as cherrypicks is a macho pretender.
I've finally settled on Sublime Merge. Same speedy interface as Sublime Text along with the visual history/branching/diffing that I need, but with a command palette that basically functions like a souped up CLI. I do still go to the CLI when I'm doing simple commits (or really weird complicated stuff like resetting to two commits previous to HEAD), but I probably get 85% of my work done in Sublime Merge. The tabs for multiple repos is also great. Totally worth it as far as tooling goes.
I’ve been a (paying!) customer for Tower for around 5 years. I prefer using a GUI over a CLI for git; Tower makes drag and dropping cherry picking easy, multiple select to squash etc.
Highly recommend you take a look (I’ve tried others and they were a combination of too much, too little and bad UX)
I’m also a paying customer of Tower but I stopped as soon as they moved to an expensive subscription model. The last non-subscription version still works fine for me; if and when it fails I will switch to git-fork or whatever is available at the time.
I’ve only just heard about Sublime Merge today, I’m going to check it out now. [Update: I've checked out Sublime Merge. Looks very promising, and I heartily approve of the price and licensing approach. My only immediate concern is how it lists modified and untracked files. I'm so used to seeing my changes shown as a collapsible tree that I'm not sure I can handle this more basic list view.]
I’ve been a big fan of git-fork.com, after years of Source Tree usage. It has a similar workflow but much crisper performance and some really nice features such as around search and filter.
The reason it's so popular and frequently used is... Because it's popular and frequently used. It's the ultimate in network effects.
That being said, git is a very solid system, it's just not polished very well. You could take the "plumbing" parts, throw out the "porcelain", and build an equally capable but far more usable system atop it.... Which almost nobody would use.
1. Git was used for Linux. People developing Linux also developed packages for apt. They used it to host the source since they already used it for Linux.
2. GitHub showed the file tree @ master as the main thing when viewing a repo. "where are my files" is the first thing I think when using legacy Got web uis
3. It's free
4. It's just good enough that you don't encounter problems every day. Because of this many people have never encountered a problem. Because people are mean they insult people who do encounter problems. This encourages people to not speak up.
Without needing to worry about setting up a web frontend, I can quickly and easily have as many free and lightweight repos as I want, on any server I own, with support for ssh certificate authentication. And if the server goes down, Git is offline-first, so I can keep working in my local repos until I can fix the server or relocate the repos.
Assuming that Git is bad because you saw some bad stories on Hacker News is like concluding that prehistoric people all lived in caves just because that's where the evidence was preserved. Most people who use Git aren't complaining about it, they're just quietly using it.
That’s it. It didn’t win because of some mysterious social network effect. It won because it is superior. It is beautifully designed. It does everything that it needs to do the right way. People had confidence in it because they knew that was what the kernel developers use.
It is by no means perfect but is vastly better than the alternatives.
With prior version control systems I always had the fear I could get into some situation i could not fix. With fit I have no fear of mistakes because I can revise commit messages, rebase, etc.
Git has some cryptic commands but you can write the important ones on a 5 x 7 card and get back to coding.
I think people chafe at the bit because git is so easy to use that even non-coders use it (really is ‘track changes’ in Office that easy to use? How much do you trust it?
It’s very success means that it challenges people who might not have used a version control system before.
But it also makes people feel smart. People like to feel smart, like they're using the "expert" tools.
Back then I used Mercurial, Bazaar NG, and Bitkeeper before Git. Coming to Git I was astounded that people who had used Bitkeeper (Linux devs) had created Git. Because Bitkeeper had a fairly elegant and consistent command line UI. Git does not.
I started using git because I really hated SVN and wanted to experiment with other options. I started using SVN after losing my patience with how bad VSS was. I’m pretty sure GitHub didn’t exist when I first picked up Git. If it did, I’d never heard of it.
Historically, it was more or less the first OSS distributed version control system - before that, people used Subversion, and it was much nastier to merge branches, etc.
People are right to call it not exactly user friendly, you can call "winning" despite this handicap a side effect of network effects - there's nothing that's been better enough than git that also that millions of users will organically switch to it
The world was ready for a replacement for SVN just at the moment when git hit the scene, and it was just good enough to take over. Mercurial dates to the same era and was just about as good (arguably better), and could easily have won out instead, but tiny difference in initial adoption snowballed, and so git won and mercurial lost (as did Bazaar, Fossil, etc.)
And while git is hardly perfect, a git killer needs to not just be 15% better, but hugely better; a big enough gap to trigger another industry wide shift. "It's like git, but we made the UI 15% nicer" seems like a good sales pitch, but it's not going to motivate people into becoming evangelists for their teams to adopt it, and that's what you need. (Git, for all its flaws, was enough better than SVN that people absolutely fought to change over.)
the world was ready for SVN replacement before the SVN :) SVN was a band-aid, a stop-gap multi-repo measure on top of CVS. The word wanted multi-repo with good sync between repos and with local history, which is basically a repo too. Mercurial and Git were 2 of those new gen version controls.
>Mercurial dates to the same era and was just about as good (arguably better)
no. In particular a killer, in the sense of adoption killer, was that opinionated absence of partial transactions in Mercurial. Also branching in Mercurial wasn't that easy/cheap/natural like in Git.
>tiny difference in initial adoption snowballed
not really. If anything, BigCo-s were choosing mercurial over git because mercurial was more like rational/etc and appealed to those tech leads/architects/managers there. Didn't help. The git was built for developers by developers (basically Linus, forced to move on from BitKeeper, re-implemented and improved upon BitKeeper in application to his task in hand - ie. large distributed development). Git wasn't an obstacle/hurdle, it was the tool multiplying your productivity. (i worked on some pre-git source control tool in well pre-git times, and i remember us discussing, even filing some patents on and building some features in our tool similar to what later git brought to the wide world)
Mercurial was slower on every possible metric (albeit faster than the competition). Git felt like magic. git-svn probably helped out too, it made the transition from svn way smoother
I think one of the big things as well that propelled Git to win was the fact that it was "made by the guy who does linux", easy to remember and later GitHub/GitLab reinforced that branding.
I was a huge mercurial fan, I was also a pretty heavy user of BitBucket (which at the time was only mercurial). It was always a mouthful to talk about mercurial or bazaar. Once people started jumping from google code in 2010-2012 to GitHub, the writing was on the wall for hg.
We may be both tainted by personal experience here, just from different sides.
Back when the race was still close I actually used git and mercurial for about the same amount of time (main work stuff was still svn) and I found git to be superior in every way.
That's why I'm cautious to attribute anything I noticed to either one winning. mercurial wasn't bad at all, but it was just a tiny bit worse than git for everything I tried.
1. distributed version control systems (dvcs) are a lot more complex than people think they are. (This is anecdotal/personal, but a _lot_ of blogs and complaints I read about git primarily boil down to complaints that are intrinsic to dvcs. It's not possible to do any better unless you either drop support for important features or come up with a novel and creative solution that somehow makes things easier to understand without losing any power. I'm not sure such an 'easier but just as powerful' model exists). In other words, lots of these complaints sound like 'the pizzas at this restaurant are crap' but the actual problem is that the complainer simply fundamentally dislikes round things, and they've misplaced most of the blame. Not something a restaurant can fix without reimagining pizzas.
2. The really easy to understand systems (such as cvs / svn) are too simple and can't do many important things, so those aren't suitable replacements.
3. Because dvcs is hard and git is the de-facto standard, in order to 'shop around' and use something else (or, build something better), you'd first need to fully understand all the particular principles of dvcs.
4. If you don't bother to learn all that or aren't capable, then you won't do a good job on finding another dvcs or building one yourself. You can't rely on outside advice - you won't be able to follow the reasoning, and you can't rely on appeal to popularity (as git is the popular choice).
5. If you DO bother to learn all that, you'll understand git so there isn't actually any reason. There is very little you'd want to do with a dvcs that git cannot do. Git's shortcomings can be solved by writing tutorials, front-ends to it, and setting up a model ('we develop features like this, we sign off on commits like this, this is how we name our tags, etc'). Not by writing something else.
> The really easy to understand systems (such as cvs / svn) are too simple and can't do many important things, so those aren't suitable replacements.
SVN internals are more complex than Git. Also there is a branch/merge semantic in SVN/CVS that is a way harder to comprehend and to predict merge outcomes. I think it had a crucial role in Git's rising. Git has Branches like in SVN and painless merging.
I find git quite easy to use with egit. I've been using git for more than 10 years. There are two types of people I see struggle with git.
People moving from CVS/SVN to git would have a hard time because the terminology is the same, but means something conceptually different. A git commit is not the same as a commit in SVN.
The other group is people who don't understand version control very well with any system. This group existed before git and will always exist. I believe for these people, git undo or whatever other "easy mode" will simply muddy the water further for them. If you don't know the difference between a revert and a reset, you need to learn it, not try to paper over it with yet another command. undo will simply add to their confusion as they don't understand any of the nuance with git.
66 comments
[ 2.8 ms ] story [ 125 ms ] thread2. You don't need an IT support ticket to set up a new repository.
3. It's distributed and supports collaborative development in a way that "classical" version control (CVS, SVN, and similar models) does not.
4. You don't need a chain of approval signatures to create a new branch.
5. It's free.
In this way it is a bit like capitalism.
Before git, the most popular SCM tool was SVN, which required you to talk to a central server for everything you do (single point of failure, slower, no offline). I've used mercurial before too, and its approach to branching is pretty painful.
I've heard of some enterprise companies needing to use git alternatives for very specific needs or scalability issues, but outside of that IMO the only meaningful downside to git is that there's a learning curve to using it. But it's not much of one - once you understand the mental model and what the basic commands are doing, you can get by just fine. The average person doesn't need to know about git rerere or octopus merging.
(also, commits are effectively immutable for public projects, which sucks for trans engineers who change their name)
I thought Mercurial was slightly superior (esp. on Windows.) But it's not better enough not to use what everyone else is using.
Personally, whenever git was unable to do something I needed it to, I have always been able to add a git alias to my `.gitconfig` that became a new part of my workflow, essentially extending the CLI. I've found it to be easy to work with, and the amount of great tooling I've found built on top of it is amazing.
I've never used a version control system other than git though. So I am heavily biased. Before I was introduced to git, I didn't use version control at all, and so maybe it's a case of the grass is always greener. But I came from a place without any grass at all.
Late 2000s/Early 2010s there was greater variety in version control tooling. Distributed VCS was new. Mercurial promised to be the “easy” version. Subversion was still heavily used and maintained.
GitHub quickly established itself as THE place to share and collaborate code. To use it you had to learn git.
Most people, still, to this day have a fairly shallow understanding of git and find themselves encountering lots of foot guns, lack of opinions, and UI inconsistencies. I’m not sure without GitHub, git would be as dominant.
git didn't solve this problem hard enough (it still has merge commits and honestly I would like to see a model that doesn't have them at all, however that would work) but at least it was fast.
[1] https://github.blog/2017-03-20-sha-1-collision-detection-on-...
Darcs was a nice system, but with the unfixed(?) massive slowdown it just wasn't workable. We toyed with mercurial, but settled on git within a year or so.
I use CLI for committing/pushing/branching etc... But anyone who pretends that CLI is adequate for inspecting history and changes or operations such as cherrypicks is a macho pretender.
It's a great tool, except for it literally will take up 100% of your mac CPU. It's been this way for years.
Highly recommend you take a look (I’ve tried others and they were a combination of too much, too little and bad UX)
I’ve only just heard about Sublime Merge today, I’m going to check it out now. [Update: I've checked out Sublime Merge. Looks very promising, and I heartily approve of the price and licensing approach. My only immediate concern is how it lists modified and untracked files. I'm so used to seeing my changes shown as a collapsible tree that I'm not sure I can handle this more basic list view.]
If you are handling hard problems in cm and build you write scripts.
That's me! The following alias in ~/.gitconfig makes things much easier:
"There are two types of version control systems: the ones people complain about and the ones no one uses."
That being said, git is a very solid system, it's just not polished very well. You could take the "plumbing" parts, throw out the "porcelain", and build an equally capable but far more usable system atop it.... Which almost nobody would use.
1. Git was used for Linux. People developing Linux also developed packages for apt. They used it to host the source since they already used it for Linux.
2. GitHub showed the file tree @ master as the main thing when viewing a repo. "where are my files" is the first thing I think when using legacy Got web uis
3. It's free
4. It's just good enough that you don't encounter problems every day. Because of this many people have never encountered a problem. Because people are mean they insult people who do encounter problems. This encourages people to not speak up.
5. Other VCSs were way slower.
Assuming that Git is bad because you saw some bad stories on Hacker News is like concluding that prehistoric people all lived in caves just because that's where the evidence was preserved. Most people who use Git aren't complaining about it, they're just quietly using it.
With prior version control systems I always had the fear I could get into some situation i could not fix. With fit I have no fear of mistakes because I can revise commit messages, rebase, etc.
Git has some cryptic commands but you can write the important ones on a 5 x 7 card and get back to coding.
I think people chafe at the bit because git is so easy to use that even non-coders use it (really is ‘track changes’ in Office that easy to use? How much do you trust it?
It’s very success means that it challenges people who might not have used a version control system before.
But it also makes people feel smart. People like to feel smart, like they're using the "expert" tools.
Back then I used Mercurial, Bazaar NG, and Bitkeeper before Git. Coming to Git I was astounded that people who had used Bitkeeper (Linux devs) had created Git. Because Bitkeeper had a fairly elegant and consistent command line UI. Git does not.
People are right to call it not exactly user friendly, you can call "winning" despite this handicap a side effect of network effects - there's nothing that's been better enough than git that also that millions of users will organically switch to it
Since then though, it's mostly network effects.
2. Timing
The world was ready for a replacement for SVN just at the moment when git hit the scene, and it was just good enough to take over. Mercurial dates to the same era and was just about as good (arguably better), and could easily have won out instead, but tiny difference in initial adoption snowballed, and so git won and mercurial lost (as did Bazaar, Fossil, etc.)
And while git is hardly perfect, a git killer needs to not just be 15% better, but hugely better; a big enough gap to trigger another industry wide shift. "It's like git, but we made the UI 15% nicer" seems like a good sales pitch, but it's not going to motivate people into becoming evangelists for their teams to adopt it, and that's what you need. (Git, for all its flaws, was enough better than SVN that people absolutely fought to change over.)
the world was ready for SVN replacement before the SVN :) SVN was a band-aid, a stop-gap multi-repo measure on top of CVS. The word wanted multi-repo with good sync between repos and with local history, which is basically a repo too. Mercurial and Git were 2 of those new gen version controls.
>Mercurial dates to the same era and was just about as good (arguably better)
no. In particular a killer, in the sense of adoption killer, was that opinionated absence of partial transactions in Mercurial. Also branching in Mercurial wasn't that easy/cheap/natural like in Git.
>tiny difference in initial adoption snowballed
not really. If anything, BigCo-s were choosing mercurial over git because mercurial was more like rational/etc and appealed to those tech leads/architects/managers there. Didn't help. The git was built for developers by developers (basically Linus, forced to move on from BitKeeper, re-implemented and improved upon BitKeeper in application to his task in hand - ie. large distributed development). Git wasn't an obstacle/hurdle, it was the tool multiplying your productivity. (i worked on some pre-git source control tool in well pre-git times, and i remember us discussing, even filing some patents on and building some features in our tool similar to what later git brought to the wide world)
I think one of the big things as well that propelled Git to win was the fact that it was "made by the guy who does linux", easy to remember and later GitHub/GitLab reinforced that branding.
I was a huge mercurial fan, I was also a pretty heavy user of BitBucket (which at the time was only mercurial). It was always a mouthful to talk about mercurial or bazaar. Once people started jumping from google code in 2010-2012 to GitHub, the writing was on the wall for hg.
Back when the race was still close I actually used git and mercurial for about the same amount of time (main work stuff was still svn) and I found git to be superior in every way.
That's why I'm cautious to attribute anything I noticed to either one winning. mercurial wasn't bad at all, but it was just a tiny bit worse than git for everything I tried.
1. distributed version control systems (dvcs) are a lot more complex than people think they are. (This is anecdotal/personal, but a _lot_ of blogs and complaints I read about git primarily boil down to complaints that are intrinsic to dvcs. It's not possible to do any better unless you either drop support for important features or come up with a novel and creative solution that somehow makes things easier to understand without losing any power. I'm not sure such an 'easier but just as powerful' model exists). In other words, lots of these complaints sound like 'the pizzas at this restaurant are crap' but the actual problem is that the complainer simply fundamentally dislikes round things, and they've misplaced most of the blame. Not something a restaurant can fix without reimagining pizzas.
2. The really easy to understand systems (such as cvs / svn) are too simple and can't do many important things, so those aren't suitable replacements.
3. Because dvcs is hard and git is the de-facto standard, in order to 'shop around' and use something else (or, build something better), you'd first need to fully understand all the particular principles of dvcs.
4. If you don't bother to learn all that or aren't capable, then you won't do a good job on finding another dvcs or building one yourself. You can't rely on outside advice - you won't be able to follow the reasoning, and you can't rely on appeal to popularity (as git is the popular choice).
5. If you DO bother to learn all that, you'll understand git so there isn't actually any reason. There is very little you'd want to do with a dvcs that git cannot do. Git's shortcomings can be solved by writing tutorials, front-ends to it, and setting up a model ('we develop features like this, we sign off on commits like this, this is how we name our tags, etc'). Not by writing something else.
SVN internals are more complex than Git. Also there is a branch/merge semantic in SVN/CVS that is a way harder to comprehend and to predict merge outcomes. I think it had a crucial role in Git's rising. Git has Branches like in SVN and painless merging.
I find git quite easy to use with egit. I've been using git for more than 10 years. There are two types of people I see struggle with git.
People moving from CVS/SVN to git would have a hard time because the terminology is the same, but means something conceptually different. A git commit is not the same as a commit in SVN.
The other group is people who don't understand version control very well with any system. This group existed before git and will always exist. I believe for these people, git undo or whatever other "easy mode" will simply muddy the water further for them. If you don't know the difference between a revert and a reset, you need to learn it, not try to paper over it with yet another command. undo will simply add to their confusion as they don't understand any of the nuance with git.
here's a thread where some of it is being discussed: https://news.ycombinator.com/item?id=27579701
/s