4 ms·

hg came before git, you have your network effect backwards. The reason git ended up overtaking mercurial is because git is more flexible. Programmers for close

hg came before git, you have your network effect backwards. The reason git ended up overtaking mercurial is because git is more flexible. Programmers for closed-source enterprise projects worldwide flocked to git because git can be massaged into any existing development process almost painlessly. Mercurial, in contrast, is "opinionated". (Before you mention github -- the timeline here is also backwards, github became the de-facto standard riding on the coattails of git's success.)

ngoldbaum 11y ago
I'm curious what makes you say that. From my point of view the exact opposite is true. Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow.
- otabdeveloper 11y ago
  >I'm curious what makes you say that. The experience of migrating to DVCS's. (Anecdotal, I know, but still...) >...but with git you're pretty much stuck with the "standard feature branching" workflow. Git is a loose collection of file manipulation utilities, it can be cobbled together to support even the most insane workflows.
- exDM69 11y ago
  > Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow. Mercurial is internally more complex than Git, as shown by the concepts you mention (bookmarks, named branches, etc) and all the various extensions. By contrast, Git is just a malleable graph of patches and tools to manipulate it. This is very well explained in the first commit(!) of git, which explains the concepts and the internal database layout. In Git, there might be a "default workflow" that the tools are geared towards but you can use rebase and cherry-pick and all the other tools to enable just about any workflow you can imagine. Of course, this allows you to turn it into a big mess and there are some weak spots (like tracking a lot of bugfix commits backported to several release branches) but the concept is simple and sound.
  - reality_czech 11y ago
    This. Absolutely this. It's ironic how many people claim that Mercurial is simpler, when actually git is much simpler and more elegant. You don't need named branches, bookmarks, extensions, and all that stuff. Just a graph of commits. The core of git is beautifully simple. I don't know what's more frustrating-- people who think DVCSes need to be really really complicated, or people who endlessly complain over what color the command-line bikeshed is painted.
nailer 11y ago
> hg came before git, you have your network effect backwards. Can you explain? Not sure how hg being released earlier changes how many users they have. See https://en.wikipedia.org/wiki/Network_effect https://en.wikipedia.org/wiki/Network_effect
azinman2 11y ago
Time line isn't the same thing as network effect. GitHub and Linux gave git the network effect.

ngoldbaum 11y ago

I'm curious what makes you say that. From my point of view the exact opposite is true. Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow.

otabdeveloper 11y ago
>I'm curious what makes you say that. The experience of migrating to DVCS's. (Anecdotal, I know, but still...) >...but with git you're pretty much stuck with the "standard feature branching" workflow. Git is a loose collection of file manipulation utilities, it can be cobbled together to support even the most insane workflows.
exDM69 11y ago
> Mercurial allows many different workflows (bookmarks, anonymous heads, named branches, topics), but with git you're pretty much stuck with the "standard feature branching" workflow. Mercurial is internally more complex than Git, as shown by the concepts you mention (bookmarks, named branches, etc) and all the various extensions. By contrast, Git is just a malleable graph of patches and tools to manipulate it. This is very well explained in the first commit(!) of git, which explains the concepts and the internal database layout. In Git, there might be a "default workflow" that the tools are geared towards but you can use rebase and cherry-pick and all the other tools to enable just about any workflow you can imagine. Of course, this allows you to turn it into a big mess and there are some weak spots (like tracking a lot of bugfix commits backported to several release branches) but the concept is simple and sound.
- reality_czech 11y ago
  This. Absolutely this. It's ironic how many people claim that Mercurial is simpler, when actually git is much simpler and more elegant. You don't need named branches, bookmarks, extensions, and all that stuff. Just a graph of commits. The core of git is beautifully simple. I don't know what's more frustrating-- people who think DVCSes need to be really really complicated, or people who endlessly complain over what color the command-line bikeshed is painted.

nailer 11y ago

> hg came before git, you have your network effect backwards. Can you explain? Not sure how hg being released earlier changes how many users they have. See https://en.wikipedia.org/wiki/Network_effect https://en.wikipedia.org/wiki/Network_effect

azinman2 11y ago

Time line isn't the same thing as network effect. GitHub and Linux gave git the network effect.