4 ms·

I rarely have geeky conversations with anyone (since I don't know any and that is why I hang out here) but I'm genuinely curious: Why is git more popular than

by philtar 13y ago

I rarely have geeky conversations with anyone (since I don't know any and that is why I hang out here) but I'm genuinely curious: Why is git more popular than hg? I tried both and hg was generally easier (for me) to pick up. I'm sure it's not JUST because of github.

nilved 13y ago
It isn't _just_ GitHub, but it's 90% GitHub. And 10% Torvalds. The important part is that it's 0% actual, useful reasons.
anton_gogolev 13y ago
Linus is the reason, I guess. I tend to think that if Git was written by somebody other than Linus, it wouldn't have gotten so popular. After all, Git was not even envisioned as a VCS [1], and all the usual VC-related functionality has been bolted onto it without a single design vision, which is why we have this clusterfuck of a CLI now. Sometime after that there was GitHub. [1]: http://marc.info/?l=linux-kernel&m=111288700902396 http://marc.info/?l=linux-kernel&m=111288700902396
harshreality 13y ago
Speed and workflow, previously. Mercurial has made up most of the difference in speed, so now git is better for some things ([temporary] topic branch workflow and history clean-up of such branches before merge is more likely to be used by git committers even if hg technically has that now, speed in a few cases, mindshare) while mercurial is better for other things like syntax, or dealing with gigantic repositories -- like Facebook's[1], but only because Facebook engineers decided that functionality was easier to add to mercurial than to git. [2] https://news.ycombinator.com/item?id=7019673 https://news.ycombinator.com/item?id=7019673
- dhimes 13y ago
  I think hg has both temporary (bookmarks) and permanent (branches) branch workflow out of the box now- and has for a while.
  - jordigh 13y ago
    And with the beta Evolve extension, we get all of the flexibility of "git push --force" with none of the dangers!
rdtsc 13y ago
3 reasons: * Linux Kernel : this means for once, great popularity. Those who commit to the kernel have quite a bit of say and influence in the industry. The tools they use get free marketing just from that. But this actually leads to the next reason --> * Speed : initially git was quite a bit faster. It had been tested and benchmarked day to day on the kernel source tree. hg, bazaar and others weren't as performant back in the day. * Github : this was the nail in the coffin of all the other DVCS-es as they say. It just came on time, with a nice interface,issues, easy to fork, do pull requests, markdown readmes etc. Not all rocket science features but it was just working very consistently and smoothly. Now I liked bazaar better if I were not to compare them on performance back in the day. I like some of its centralization options, other things. But it is kind of too late in that sense. Launchpad should have appeared, say 6 months earlier, and it should have been smoking fast. It wasn't. And so my favorite DVCS was left behind. Bitbucket is also very nice. I really like it. But well all the cool kids are on Github so some projects just moved to that. I creates kind of mono-culture and I am not sure if it is good or bad yet. At the end of the day there are 2 type of developers -- those who care about version control systems, read about them, play with them, and those that don't. This classification usually says nothing about other qualities, experience, personality traits etc. It is just the second group just cares to use it as a tool. They are willing to learn the minimum amount of command from a refcard to get their code committed. And having just one system means having one ref card only if they have to collaborate. So learning git/Github interface is the easiest way to proceed.
- tonfa 13y ago
  > Speed Actually in 2005 performance was pretty similar and for some workflows hg was definitely faster (patch + commit). Also before packs were introduced git just used massive disk space (hg had smart storage from day one).
  - jordigh 13y ago
    git is still slower than hg for some operations, such as blame and clone. I think it's fundamentally due to the nature of git's data structures, they just don't optimise for this case, but David Kastrup has boasted that he can fix git's slowness. I'm skeptical, but let's see...
wyuenho 13y ago
1) Linux and it's viral tirade on SVN on Youtube. 2) Cargo-cult computing. 3) Very strategic integration with Heroku and Xcode. Both are very important force multipliers. It was initially the Ruby folks they were the champions of Git outside of the Linus kernel devs. 4) Github. 5) Silicon Valley. SV is a very large echo chamber, the fact that Github is in the middle of it gives you an edge. Bitbucket is based out in Australia I think, there was less people to talk to, less good people for hire etc. Back in around 2008, both Github and Bitbucket were terrible.
rimantas 13y ago
Because is it better. Very simle reason, although very difficult to stomach for some.

by philtar 13y ago

nilved 13y ago

It isn't _just_ GitHub, but it's 90% GitHub. And 10% Torvalds. The important part is that it's 0% actual, useful reasons.

anton_gogolev 13y ago

Linus is the reason, I guess. I tend to think that if Git was written by somebody other than Linus, it wouldn't have gotten so popular. After all, Git was not even envisioned as a VCS [1], and all the usual VC-related functionality has been bolted onto it without a single design vision, which is why we have this clusterfuck of a CLI now. Sometime after that there was GitHub. [1]: http://marc.info/?l=linux-kernel&m=111288700902396 http://marc.info/?l=linux-kernel&m=111288700902396

harshreality 13y ago

Speed and workflow, previously. Mercurial has made up most of the difference in speed, so now git is better for some things ([temporary] topic branch workflow and history clean-up of such branches before merge is more likely to be used by git committers even if hg technically has that now, speed in a few cases, mindshare) while mercurial is better for other things like syntax, or dealing with gigantic repositories -- like Facebook's[1], but only because Facebook engineers decided that functionality was easier to add to mercurial than to git. [2] https://news.ycombinator.com/item?id=7019673 https://news.ycombinator.com/item?id=7019673

dhimes 13y ago
I think hg has both temporary (bookmarks) and permanent (branches) branch workflow out of the box now- and has for a while.
- jordigh 13y ago
  And with the beta Evolve extension, we get all of the flexibility of "git push --force" with none of the dangers!

rdtsc 13y ago

3 reasons: * Linux Kernel : this means for once, great popularity. Those who commit to the kernel have quite a bit of say and influence in the industry. The tools they use get free marketing just from that. But this actually leads to the next reason --> * Speed : initially git was quite a bit faster. It had been tested and benchmarked day to day on the kernel source tree. hg, bazaar and others weren't as performant back in the day. * Github : this was the nail in the coffin of all the other DVCS-es as they say. It just came on time, with a nice interface,issues, easy to fork, do pull requests, markdown readmes etc. Not all rocket science features but it was just working very consistently and smoothly. Now I liked bazaar better if I were not to compare them on performance back in the day. I like some of its centralization options, other things. But it is kind of too late in that sense. Launchpad should have appeared, say 6 months earlier, and it should have been smoking fast. It wasn't. And so my favorite DVCS was left behind. Bitbucket is also very nice. I really like it. But well all the cool kids are on Github so some projects just moved to that. I creates kind of mono-culture and I am not sure if it is good or bad yet. At the end of the day there are 2 type of developers -- those who care about version control systems, read about them, play with them, and those that don't. This classification usually says nothing about other qualities, experience, personality traits etc. It is just the second group just cares to use it as a tool. They are willing to learn the minimum amount of command from a refcard to get their code committed. And having just one system means having one ref card only if they have to collaborate. So learning git/Github interface is the easiest way to proceed.

tonfa 13y ago
> Speed Actually in 2005 performance was pretty similar and for some workflows hg was definitely faster (patch + commit). Also before packs were introduced git just used massive disk space (hg had smart storage from day one).
- jordigh 13y ago
  git is still slower than hg for some operations, such as blame and clone. I think it's fundamentally due to the nature of git's data structures, they just don't optimise for this case, but David Kastrup has boasted that he can fix git's slowness. I'm skeptical, but let's see...

wyuenho 13y ago

1) Linux and it's viral tirade on SVN on Youtube. 2) Cargo-cult computing. 3) Very strategic integration with Heroku and Xcode. Both are very important force multipliers. It was initially the Ruby folks they were the champions of Git outside of the Linus kernel devs. 4) Github. 5) Silicon Valley. SV is a very large echo chamber, the fact that Github is in the middle of it gives you an edge. Bitbucket is based out in Australia I think, there was less people to talk to, less good people for hire etc. Back in around 2008, both Github and Bitbucket were terrible.

rimantas 13y ago

Because is it better. Very simle reason, although very difficult to stomach for some.