14 ms·

Why is Git so popular and frequently used?

32 points by posharma 5y ago

Why is Git so popular and frequently used if this is the state (https://news.ycombinator.com/item?id=27579701)?

Jtsummers 5y ago
1. It's free. 2. 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.
deleted 5y ago
[deleted]
readonthegoapp 5y ago
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. In this way it is a bit like capitalism.
- Clewza313 5y ago
  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.
- bvrmn 5y ago
  Git has the most simple design (protocol, repo format) out there. You can implement it yourself in a couple of evenings.
  - joshka 5y ago
    Linus took a couple of weeks... Just sayin' ;)
jmcgough 5y ago
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)
ShardPhoenix 5y ago
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.
sakesun 5y ago
Network effect, perhaps
eyelidlessness 5y ago
Because mercurial lost.
- HWR_14 5y ago
  Yes. I thought Mercurial was slightly superior (esp. on Windows.) But it's not better enough not to use what everyone else is using.
vinnymac 5y ago
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.
softwaredoug 5y ago
Frankly, because of GitHub 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.
- astrange 5y ago
  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.
  - williamstein 5y ago
    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]). [1] https://github.blog/2017-03-20-sha-1-collision-detection-on-github-com/ https://github.blog/2017-03-20-sha-1-collision-detection-on-...
  - stevekemp 5y ago
    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.
BrissyCoder 5y ago
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.
- enjoiful 5y ago
  I only use Git via SourceTree. It's a great tool, except for it literally will take up 100% of your mac CPU. It's been this way for years.
- ljoshua 5y ago
  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.
- ojame 5y ago
  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)
  - simondotau 5y ago
    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.]
patrickthebold 5y ago
Whats the quote? "There are two types of version control systems: the ones people complain about and the ones no one uses."
Sophistifunk 5y ago
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.
justinator 5y ago
CVS was hell.
gravypod 5y ago
My theory: 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.
asymptosis 5y ago
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.
- leephillips 5y ago
  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.
  - underwater 5y ago
    Git is beautifully designed. The command line interface, not so much.
    - leephillips 5y ago
      Fair enough.
  - HWR_14 5y ago
    It beat Mercurial (which has the same properties) because of social network effect. All tooling has a social network effect.
PaulHoule 5y ago
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.
cmrdporcupine 5y ago
Because of GitHub. 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.
- AmericanChopper 5y ago
  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.
refulgentis 5y ago
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
fartcannon 5y ago
Originally, I think it was because it's made by Linus. People trust him and the people who make the Linux kernel so it was a natural fit. Since then though, it's mostly network effects.
smoldesu 5y ago
Git doesn't have any restrictive licensing. Anyone can install and use it for free, no questions asked.
Lazare 5y ago
1. 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.)
- trhway 5y ago
  >The world was ready for a replacement for SVN 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)
- riquito 5y ago
  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
rzwitserloot 5y ago
It's simple logic, really: 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.
- bvrmn 5y ago
  > 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.
deleted 5y ago
[deleted]
panny 5y ago
>if this is the state 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.
ChrisArchitect 5y ago
there's a whole history/check the timeline of how it rose here's a thread where some of it is being discussed: https://news.ycombinator.com/item?id=27579701 https://news.ycombinator.com/item?id=27579701 /s
indymike 5y ago
1. Git was WAY better than SVN and CVS and was also a lot better than most of the commercial options of the time. The open source license and fact it worked on just about any text file made it pretty easy to adopt. 2. Author was Linus Torvalds and git was immediately used and proven (in 2005) to manage the Linux kernel. For a lot of open source developers, experience working with kernel stuff had you thinking, hey this git thing is pretty nice... 3. When Github showed up, it quickly replaced the old SVN and CVS driven software "forges" that were used by a lot of the open source world. So what about the undo thing? Git has always got a lot of flack for it's command line inconsistency. Honestly, it's no better/no worse than most developer tools (try your compiler's command line options). You have to learn to use it, and like other dev tools, learning it usually involves on the job pain, exactly when you don't want it (demo in 15 minutes).
ericol 5y ago
Paraphrasing, "Git is the worst distributed version control system... except all the others". With an exception made of Mercury - that according to people (I never used it) was in points better than Git -, git swept the floor with the competition, with a "little" help from Github. The reality is that today you can't really separate git from Github. Regarding your link, and to answer your question, my position is that Git is like the PHP of version control. The barrier to entry is so, so low, that not enough people care about learning it right / properly /enough (Myself included) (The difference being that I can goople myself out of a problem pretty much every time). Also, I do make a pretty basic use of git, and it's been years since I screwed up. Worst case scenario I need to fix a merge conflict with code from one of my colleagues (That I hate to fix, because it doesn't happen often enough as for myself to remember how to interpret the diffs) Anecdotally, I was the person responsible for the adoption of Git in my company, some 13 years ago. We were really struggling back then to get SVN working for distributed version control. We never looked back.
dasil003 5y ago
Because git is actually very very good at what it does for the most common cases of source control. Aside from scaling edge cases it works phenomenally well and gets almost everything right. The big flaw is just the inscrutability and learning curve of the porcelain commands, however any attempt to fix that has to either nerf git's power, or else transform the complexity to another equally complex if less arbitrary set of commands and switches. I don't think such a system can ever gain traction because it only helps beginners, for the majority of seasoned developers it just amounts to new syntax to the same stuff.
JoeyBananas 5y ago
Don't believe the hype, there is really not much you could do to improve upon Git. There is a good reason why Git is not a VSCode plugin or a GUI program like inexperienced devs often expect it to be. It's an example of a program that uses unix philosophy. There is nothing stopping you from using Git through a GUI or a simplified text interface if you want, but that functionality is out of the scope of Git.
- joshka 5y ago
  fossil scm has some good ideas, but things that are obviously missing in my mind that would improve / advance the state of the art in source control: - AST based storage / diff / etc., kill the tabs vs spaces war permanently - the actual command line interface inconsistencies (mostly these just take practice, but it would be better not having them there)
rektide 5y ago
I really dislike your burried link, not mentioning what you are arguing about. > if this is the state (hn link) this is an enormous load of salt to throw while doing nothing to clarify or make clear where umbrage might be taken. poor form of "question asking" & does a disservice to possible conversations, by not making a case, just being nasty. you should at least try to communicate a case for your distaste, so as not to present as so easily disregarding & dismissing without real interest. you seem unwilling from the start to be accepting.
ytch 5y ago
Before Github, many OSS are hosted at Sourceforge. but IIRC, you need Sourceforge's approve to open a new project. Unlike Github, which you can open a public repository by yourself. Then Ruby (and ruby gems?) is hosted at Github, as Ruby/RoR gets more attention, Github and Git become popular too.
joshka 5y ago
* 2005 Linus invents git to get around licensing issues with bitkeeper. * 2005 Git into use shortly in the Linux kernel * late 2000s, SourceForge kinda got bad - trying to do too many things badly in complex interfaces * 2008 github comes around - it's simple and obvious (shiny, new), open source projects start to move over - exponential growth due to network effects * 2009 github gets big. That era of the web was all bootstrap themes with sites just implementing features as fast as possible, lots of fast growth * 2010 github has 1M repos * 2010 microsoft TFS goes git based Understanding what git replaced is a key for this. For me the main thing git did right in that period that made me want to change from the various SCMs I used at the time (CVS/SVN/SourceSafe/Perforce/TFS) was that source control becomes a part of development, done locally. There's only one machine (yours) that breaks when you break a merge / integration / rebase etc. The server is not really part of the "I'm done with my change, now share my change with others" loop that is part of every team based development project. This reduced that time significantly (things which often took hours or even days now took seconds). TL;DR - Workflow improvements, Linux, OSS network effects, Github's simple UI, world domination
mikewarot 5y ago
Everything in Git is addressed based on the hash of data, this automatically makes things content addressable. Git doesn't take more room if you rename a file, the contents are still at the same hash. It treats the whole repository as an object, instead of tracking each individual file. Not every command is as user friendly as it should be, but it is far, far better than having a stack of floppy disks with .ZIP files on them, which is what I used to do in the 1990s as a solo developer.
giomasce 5y ago
The thing I really like of Git is the simplicity and transparency of its structure: a Git repository is a DAG of commits, each of which is a tree of blobs and directories, all of them linked by their hashes. On top of that there are tags and branches, which are labels for some of these hashes. That's all, essentially. This makes it very easy to understand what's happening in my repositories. It makes it easy to address data: if two repositories have the same commit hash, they have exactly the same history, nothing else to check. To me understanding the data structure is more important that understanding how that data is to be manipulated. Manipulation follows from the structure, not the other way around for me. So it's true that git's interface can be a bit confusing, but if you know what you want to get, eventually you find out how to do it. Much worse would be to understand if you did the right thing with a repository whose internal structure is opaque to you. Also, manipulation tools can be fixed, enhanced, redesigned, developed, and git's user interface has definitely progressed since its beginning. Data at rest is more difficult to fix if you laid it out wrong (as the transition away from SHA1 proves: that's one thing that was not engineered well enough at the beginning and it has a price now). So having a solid data layout is more important that having an easy interface. These are the reasons for my love at first sight with git.
Thristle 5y ago
Before I started programming I mainly got my open source source code from SVN. Back at the day all the emulators were hosted on SVN + google code (I think?), I didn't even know git existed. I felt the shift to git in projects I use happen only after github launched and became popular and with the "fall" of google code, all the projects just naturally moved to github + git so main points 1.git works (not that other SCM don't) 2.github is huge and very easy to use 3.the decentralized way of git seems more "natural" to me (subjective, obviously)
peterhi 5y ago
We used mercurial but few tools integrated with it out of the box. It was easier to move to git that get mercurial to work with our tools
s_m 5y ago
In the late 00's, SVN was the dominant version control system, but it had lots of pain points (eg reliant on remote server, lots of crappy little .svn directories, branching was difficult, very difficult to make a git repo for small projects etc) that Git resolved. At this time, hg and bzr were also on the scene, but Github quickly became incredible popular, for a few reasons - Sourceforce, the incumbent community home for open source, was a comparatively inferior user experience - Rails, which was a dominant OSS project in that era, was hosted there, and the Rails / Ruby community converged on GH as a result - Heroku was a trendy platform during this time, which at the time you deployed by `git push`-ing, so git knowledge was required to take advantage of it.

32 points by posharma 5y ago

Why is Git so popular and frequently used if this is the state (https://news.ycombinator.com/item?id=27579701)?

1. It's free. 2. 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.

deleted 5y ago

[deleted]

readonthegoapp 5y ago

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. In this way it is a bit like capitalism.

Clewza313 5y ago
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.
bvrmn 5y ago
Git has the most simple design (protocol, repo format) out there. You can implement it yourself in a couple of evenings.
- joshka 5y ago
  Linus took a couple of weeks... Just sayin' ;)

jmcgough 5y ago

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)

ShardPhoenix 5y ago

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.

sakesun 5y ago

Network effect, perhaps

eyelidlessness 5y ago

Because mercurial lost.

HWR_14 5y ago
Yes. I thought Mercurial was slightly superior (esp. on Windows.) But it's not better enough not to use what everyone else is using.

vinnymac 5y ago

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.

softwaredoug 5y ago

Frankly, because of GitHub 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.

astrange 5y ago
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.
- williamstein 5y ago
  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]). [1] https://github.blog/2017-03-20-sha-1-collision-detection-on-github-com/ https://github.blog/2017-03-20-sha-1-collision-detection-on-...
- stevekemp 5y ago
  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.

BrissyCoder 5y ago

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.

enjoiful 5y ago
I only use Git via SourceTree. It's a great tool, except for it literally will take up 100% of your mac CPU. It's been this way for years.
ljoshua 5y ago
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.
ojame 5y ago
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)
- simondotau 5y ago
  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.]

patrickthebold 5y ago

Whats the quote? "There are two types of version control systems: the ones people complain about and the ones no one uses."

Sophistifunk 5y ago

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.

justinator 5y ago

CVS was hell.

gravypod 5y ago

My theory: 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.

asymptosis 5y ago

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.

leephillips 5y ago
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.
- underwater 5y ago
  Git is beautifully designed. The command line interface, not so much.
  - leephillips 5y ago
    Fair enough.
- HWR_14 5y ago
  It beat Mercurial (which has the same properties) because of social network effect. All tooling has a social network effect.

PaulHoule 5y ago

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.

cmrdporcupine 5y ago

Because of GitHub. 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.

AmericanChopper 5y ago
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.

refulgentis 5y ago

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

fartcannon 5y ago

Originally, I think it was because it's made by Linus. People trust him and the people who make the Linux kernel so it was a natural fit. Since then though, it's mostly network effects.

smoldesu 5y ago

Git doesn't have any restrictive licensing. Anyone can install and use it for free, no questions asked.

Lazare 5y ago

1. 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.)

trhway 5y ago
>The world was ready for a replacement for SVN 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)
riquito 5y ago
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

rzwitserloot 5y ago

It's simple logic, really: 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.

bvrmn 5y ago
> 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.

deleted 5y ago

[deleted]

panny 5y ago

>if this is the state 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.

ChrisArchitect 5y ago

there's a whole history/check the timeline of how it rose here's a thread where some of it is being discussed: https://news.ycombinator.com/item?id=27579701 https://news.ycombinator.com/item?id=27579701 /s

indymike 5y ago

1. Git was WAY better than SVN and CVS and was also a lot better than most of the commercial options of the time. The open source license and fact it worked on just about any text file made it pretty easy to adopt. 2. Author was Linus Torvalds and git was immediately used and proven (in 2005) to manage the Linux kernel. For a lot of open source developers, experience working with kernel stuff had you thinking, hey this git thing is pretty nice... 3. When Github showed up, it quickly replaced the old SVN and CVS driven software "forges" that were used by a lot of the open source world. So what about the undo thing? Git has always got a lot of flack for it's command line inconsistency. Honestly, it's no better/no worse than most developer tools (try your compiler's command line options). You have to learn to use it, and like other dev tools, learning it usually involves on the job pain, exactly when you don't want it (demo in 15 minutes).

ericol 5y ago

Paraphrasing, "Git is the worst distributed version control system... except all the others". With an exception made of Mercury - that according to people (I never used it) was in points better than Git -, git swept the floor with the competition, with a "little" help from Github. The reality is that today you can't really separate git from Github. Regarding your link, and to answer your question, my position is that Git is like the PHP of version control. The barrier to entry is so, so low, that not enough people care about learning it right / properly /enough (Myself included) (The difference being that I can goople myself out of a problem pretty much every time). Also, I do make a pretty basic use of git, and it's been years since I screwed up. Worst case scenario I need to fix a merge conflict with code from one of my colleagues (That I hate to fix, because it doesn't happen often enough as for myself to remember how to interpret the diffs) Anecdotally, I was the person responsible for the adoption of Git in my company, some 13 years ago. We were really struggling back then to get SVN working for distributed version control. We never looked back.

dasil003 5y ago

Because git is actually very very good at what it does for the most common cases of source control. Aside from scaling edge cases it works phenomenally well and gets almost everything right. The big flaw is just the inscrutability and learning curve of the porcelain commands, however any attempt to fix that has to either nerf git's power, or else transform the complexity to another equally complex if less arbitrary set of commands and switches. I don't think such a system can ever gain traction because it only helps beginners, for the majority of seasoned developers it just amounts to new syntax to the same stuff.

JoeyBananas 5y ago

Don't believe the hype, there is really not much you could do to improve upon Git. There is a good reason why Git is not a VSCode plugin or a GUI program like inexperienced devs often expect it to be. It's an example of a program that uses unix philosophy. There is nothing stopping you from using Git through a GUI or a simplified text interface if you want, but that functionality is out of the scope of Git.

joshka 5y ago
fossil scm has some good ideas, but things that are obviously missing in my mind that would improve / advance the state of the art in source control: - AST based storage / diff / etc., kill the tabs vs spaces war permanently - the actual command line interface inconsistencies (mostly these just take practice, but it would be better not having them there)

rektide 5y ago

I really dislike your burried link, not mentioning what you are arguing about. > if this is the state (hn link) this is an enormous load of salt to throw while doing nothing to clarify or make clear where umbrage might be taken. poor form of "question asking" & does a disservice to possible conversations, by not making a case, just being nasty. you should at least try to communicate a case for your distaste, so as not to present as so easily disregarding & dismissing without real interest. you seem unwilling from the start to be accepting.

ytch 5y ago

Before Github, many OSS are hosted at Sourceforge. but IIRC, you need Sourceforge's approve to open a new project. Unlike Github, which you can open a public repository by yourself. Then Ruby (and ruby gems?) is hosted at Github, as Ruby/RoR gets more attention, Github and Git become popular too.

joshka 5y ago

* 2005 Linus invents git to get around licensing issues with bitkeeper. * 2005 Git into use shortly in the Linux kernel * late 2000s, SourceForge kinda got bad - trying to do too many things badly in complex interfaces * 2008 github comes around - it's simple and obvious (shiny, new), open source projects start to move over - exponential growth due to network effects * 2009 github gets big. That era of the web was all bootstrap themes with sites just implementing features as fast as possible, lots of fast growth * 2010 github has 1M repos * 2010 microsoft TFS goes git based Understanding what git replaced is a key for this. For me the main thing git did right in that period that made me want to change from the various SCMs I used at the time (CVS/SVN/SourceSafe/Perforce/TFS) was that source control becomes a part of development, done locally. There's only one machine (yours) that breaks when you break a merge / integration / rebase etc. The server is not really part of the "I'm done with my change, now share my change with others" loop that is part of every team based development project. This reduced that time significantly (things which often took hours or even days now took seconds). TL;DR - Workflow improvements, Linux, OSS network effects, Github's simple UI, world domination

mikewarot 5y ago

Everything in Git is addressed based on the hash of data, this automatically makes things content addressable. Git doesn't take more room if you rename a file, the contents are still at the same hash. It treats the whole repository as an object, instead of tracking each individual file. Not every command is as user friendly as it should be, but it is far, far better than having a stack of floppy disks with .ZIP files on them, which is what I used to do in the 1990s as a solo developer.

giomasce 5y ago

The thing I really like of Git is the simplicity and transparency of its structure: a Git repository is a DAG of commits, each of which is a tree of blobs and directories, all of them linked by their hashes. On top of that there are tags and branches, which are labels for some of these hashes. That's all, essentially. This makes it very easy to understand what's happening in my repositories. It makes it easy to address data: if two repositories have the same commit hash, they have exactly the same history, nothing else to check. To me understanding the data structure is more important that understanding how that data is to be manipulated. Manipulation follows from the structure, not the other way around for me. So it's true that git's interface can be a bit confusing, but if you know what you want to get, eventually you find out how to do it. Much worse would be to understand if you did the right thing with a repository whose internal structure is opaque to you. Also, manipulation tools can be fixed, enhanced, redesigned, developed, and git's user interface has definitely progressed since its beginning. Data at rest is more difficult to fix if you laid it out wrong (as the transition away from SHA1 proves: that's one thing that was not engineered well enough at the beginning and it has a price now). So having a solid data layout is more important that having an easy interface. These are the reasons for my love at first sight with git.

Thristle 5y ago

Before I started programming I mainly got my open source source code from SVN. Back at the day all the emulators were hosted on SVN + google code (I think?), I didn't even know git existed. I felt the shift to git in projects I use happen only after github launched and became popular and with the "fall" of google code, all the projects just naturally moved to github + git so main points 1.git works (not that other SCM don't) 2.github is huge and very easy to use 3.the decentralized way of git seems more "natural" to me (subjective, obviously)

peterhi 5y ago

We used mercurial but few tools integrated with it out of the box. It was easier to move to git that get mercurial to work with our tools

s_m 5y ago

In the late 00's, SVN was the dominant version control system, but it had lots of pain points (eg reliant on remote server, lots of crappy little .svn directories, branching was difficult, very difficult to make a git repo for small projects etc) that Git resolved. At this time, hg and bzr were also on the scene, but Github quickly became incredible popular, for a few reasons - Sourceforce, the incumbent community home for open source, was a comparatively inferior user experience - Rails, which was a dominant OSS project in that era, was hosted there, and the Rails / Ruby community converged on GH as a result - Heroku was a trendy platform during this time, which at the time you deployed by `git push`-ing, so git knowledge was required to take advantage of it.