5 ms·

The interesting thing about git is, that while it is heavily criticised for begin difficult, it is such a huge success. Most of the time, criticism of git can

by wirrbel 10y ago

The interesting thing about git is, that while it is heavily criticised for begin difficult, it is such a huge success. Most of the time, criticism of git can be summarized as "Bad user experience", which is often blamed on git exposing its implementation details. I.e. most git criticism proposes that the backend of the VCS should be "private" and the user should see a carefully designed UI, that is optimized for workflows. I think we don't need to redesign git in such a way, for the mere fact, that we already have a mature, distributed version control system that has a carefully designed UI and has a core that is opaque to the user: mercurial In fact, given mercurial's age, the availability of github-like hosting services (bitbucket offered mercurial hosting for years) raise a very important question, that I would like "git-reformists" to answer as part of their critique: Why has git won more market share than mercurial? My feeling is, that part of what makes git hard to new users is a "killer feature" for intermediate and advanced users. I.e. having a basic understanding of how git manages its data makes hardly leaves me with situations and repository states that I cannot resolve. Whereas in mercurial, I feel pretty much lost when I want to do something that has not been an implemented workflow. Maybe, now that we know a lot more about DVCS workflows than we did at the time when mercurial and git were young, a new workflow-oriented VCS might make better workflow choices. Until then, I happily stay with git.

pjmlp 10y ago
> Why has git won more market share than mercurial? Because Git is used by Linux and was designed by Linus. Those facts alone are good enough for most people to choose git over something else, not the technical ones. Just like UNIX and JavaScript, technically better is not always what wins.
- andai 10y ago
  UNIX and JavaScript?
  - gcp 10y ago
    They're (counter)examples. Bad things that won. "Worse is better" etc.
    - MEHColeman 10y ago
      Genuinely curious: which OS ought to have beaten UNIX?
      - pjmlp 10y ago
        Any of those designed at Xerox PARC, or security minded ones designed in the 60's like Burroughs.
      - guitarbill 10y ago
        So am I. Maybe BSD?
      - prewett 10y ago
        The Unix team created Plan 9 to supercede it, so that's the logical choice. BeOS had a lot of fans, too. (Completely unrelated, I just discovered that the Plan 9 logo bears a striking resemblance to the Go logo [see the Wikipedia link]. Given Rob Pike's influence, I'm sure that is not a coincidence.) [1] https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
      - johnfjacobi 10y ago
        I'm also wondering this. I have not seen an OS superior to *NIX systems, UNIX in particular, when you add the context of era.
  - patkai 10y ago
    Nobody asked about JS, apparently that's clear :)
- akvadrako 10y ago
  It's all because of this. Before git there was also monotone, which was fast and my personal favorite. But Linus tried it once and that specific version happened to have a performance regression so he decided to rebuild the whole toolchain from scratch. Honestly it's a good story about the power of marketing and I feel a bit sorry for the monotone developers because they did it first and well, but get almost no recognition.
  - cesarb 10y ago
    > Before git there was also monotone, which was fast Fast? I played with OpenEmbedded (for OpenMoko) a while ago, which used monotone. From what I recall, it was slow. IIRC, slow enough that they had to use the trick of downloading a "pre-cloned" snapshot and updating it, instead of cloning from scratch.
    - akvadrako 10y ago
      We are talking about 12 years ago and since then monotone hasn't gotten much love, while the others have. I did find some benchmarks from 2009 and by then monotone shows consistent by often 5x slower performance than git: https://web.archive.org/web/20090131095353/http://ldn.linuxfoundation.org/article/dvcs-round-one-system-rule-them-all-part-3 https://web.archive.org/web/20090131095353/http://ldn.linuxf...
Mandatum 10y ago
> The interesting thing about git is, that while it is heavily criticised for begin difficult, it is such a huge success. I think it's only difficult to use if the company/people using Git don't have good Git policy.
develop7 10y ago
> _it is such a huge success_ GitHub _is_ a huge success, and git is merely comes along in a bandwagon (English isn't my native, hope I've made this clear) > Whereas in mercurial, I feel pretty much lost when I want to do something that has not been an implemented workflow. Interesting, could you give an example?
- phee 10y ago
  IIRC git was already a huge success, i.e. most big freesoftware projects (Linux, GNOME, xorg, gstreamer and many more) ditched other VCS for it, when github was still in its early stages.
  - pjmlp 10y ago
    I remember quite a few (Go, SDL, Java,Google Code repositories...) using Mercurial until switching to git due to peer pressure was unavoidable.
- josteink 10y ago
  > GitHub _is_ a huge success, and git is merely comes along in a bandwagon (English isn't my native, hope I've made this clear) It's the other way around. Git was such a huge success, so therefore someone decided to create a nice web-frontend and SASS for it. That SASS was Github.
InclinedPlane 10y ago
Why is git so successful? It has good internals and has had those good internals for years and years, which covered up for its many flaws. Add on to that: network effect due to linux, github, and gitlab all using git. Git is great, compared to most of the alternatives. But is it perfect? Of course not. Is it hugely flawed in parts? Of course it is. It has a UX designed by freaking engineers FFS, it's surprising it's as usable as it is. The observation that git forces you to learn how its guts work so that when you inevitably end up in some scary situation with the potential of losing or screwing up revision history you know enough to work your way out of it is not a strong argument. It's similar to the lament about how older cars were so much easier to work on and that made them better. Better if you want to work on cars, perhaps, but a vehicle that requires constant maintenance is not superior to today's cars that can be run for 100k miles with minimal engine work and a single set of spark plugs, and are also safer, more efficient, and cleaner to boot. The same thing goes for VCSes, if you're regularly, or ever, getting into hairy revision history problems that's a sign of a weakness in your VCS and/or workflow.
marcinkuzminski 10y ago
> I.e. having a basic understanding of how git manages its data makes hardly leaves me with situations and repository states that I cannot resolve. If your dvcs allows you to get to that odd situation then it's already bad. Think about it as a tool for masses, maybe someone really familiar with GIT internals can resolve all odd situations, but imagine introducing GIT into an Organization with 1000 SVN users. The costs of all the guys learning in depth git is just too big.

by wirrbel 10y ago

pjmlp 10y ago

> Why has git won more market share than mercurial? Because Git is used by Linux and was designed by Linus. Those facts alone are good enough for most people to choose git over something else, not the technical ones. Just like UNIX and JavaScript, technically better is not always what wins.

andai 10y ago
UNIX and JavaScript?
- gcp 10y ago
  They're (counter)examples. Bad things that won. "Worse is better" etc.
  - MEHColeman 10y ago
    Genuinely curious: which OS ought to have beaten UNIX?
    - pjmlp 10y ago
      Any of those designed at Xerox PARC, or security minded ones designed in the 60's like Burroughs.
    - guitarbill 10y ago
      So am I. Maybe BSD?
    - prewett 10y ago
      The Unix team created Plan 9 to supercede it, so that's the logical choice. BeOS had a lot of fans, too. (Completely unrelated, I just discovered that the Plan 9 logo bears a striking resemblance to the Go logo [see the Wikipedia link]. Given Rob Pike's influence, I'm sure that is not a coincidence.) [1] https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
    - johnfjacobi 10y ago
      I'm also wondering this. I have not seen an OS superior to *NIX systems, UNIX in particular, when you add the context of era.
- patkai 10y ago
  Nobody asked about JS, apparently that's clear :)
akvadrako 10y ago
It's all because of this. Before git there was also monotone, which was fast and my personal favorite. But Linus tried it once and that specific version happened to have a performance regression so he decided to rebuild the whole toolchain from scratch. Honestly it's a good story about the power of marketing and I feel a bit sorry for the monotone developers because they did it first and well, but get almost no recognition.
- cesarb 10y ago
  > Before git there was also monotone, which was fast Fast? I played with OpenEmbedded (for OpenMoko) a while ago, which used monotone. From what I recall, it was slow. IIRC, slow enough that they had to use the trick of downloading a "pre-cloned" snapshot and updating it, instead of cloning from scratch.
  - akvadrako 10y ago
    We are talking about 12 years ago and since then monotone hasn't gotten much love, while the others have. I did find some benchmarks from 2009 and by then monotone shows consistent by often 5x slower performance than git: https://web.archive.org/web/20090131095353/http://ldn.linuxfoundation.org/article/dvcs-round-one-system-rule-them-all-part-3 https://web.archive.org/web/20090131095353/http://ldn.linuxf...

Mandatum 10y ago

> The interesting thing about git is, that while it is heavily criticised for begin difficult, it is such a huge success. I think it's only difficult to use if the company/people using Git don't have good Git policy.

develop7 10y ago

> _it is such a huge success_ GitHub _is_ a huge success, and git is merely comes along in a bandwagon (English isn't my native, hope I've made this clear) > Whereas in mercurial, I feel pretty much lost when I want to do something that has not been an implemented workflow. Interesting, could you give an example?

phee 10y ago
IIRC git was already a huge success, i.e. most big freesoftware projects (Linux, GNOME, xorg, gstreamer and many more) ditched other VCS for it, when github was still in its early stages.
- pjmlp 10y ago
  I remember quite a few (Go, SDL, Java,Google Code repositories...) using Mercurial until switching to git due to peer pressure was unavoidable.
josteink 10y ago
> GitHub _is_ a huge success, and git is merely comes along in a bandwagon (English isn't my native, hope I've made this clear) It's the other way around. Git was such a huge success, so therefore someone decided to create a nice web-frontend and SASS for it. That SASS was Github.

InclinedPlane 10y ago

Why is git so successful? It has good internals and has had those good internals for years and years, which covered up for its many flaws. Add on to that: network effect due to linux, github, and gitlab all using git. Git is great, compared to most of the alternatives. But is it perfect? Of course not. Is it hugely flawed in parts? Of course it is. It has a UX designed by freaking engineers FFS, it's surprising it's as usable as it is. The observation that git forces you to learn how its guts work so that when you inevitably end up in some scary situation with the potential of losing or screwing up revision history you know enough to work your way out of it is not a strong argument. It's similar to the lament about how older cars were so much easier to work on and that made them better. Better if you want to work on cars, perhaps, but a vehicle that requires constant maintenance is not superior to today's cars that can be run for 100k miles with minimal engine work and a single set of spark plugs, and are also safer, more efficient, and cleaner to boot. The same thing goes for VCSes, if you're regularly, or ever, getting into hairy revision history problems that's a sign of a weakness in your VCS and/or workflow.

marcinkuzminski 10y ago

> I.e. having a basic understanding of how git manages its data makes hardly leaves me with situations and repository states that I cannot resolve. If your dvcs allows you to get to that odd situation then it's already bad. Think about it as a tool for masses, maybe someone really familiar with GIT internals can resolve all odd situations, but imagine introducing GIT into an Organization with 1000 SVN users. The costs of all the guys learning in depth git is just too big.