Comment by ldayley | Hacker News Reader

Comment by ldayley | Hacker News Reader

Parent Full thread

Thank you for sharing this, Scott! He mentions "Taste" throughout the post and this intangible quality makes all the difference in an early-stage winner-take-all market dominance race.

In 2007 I was teaching myself programming and had just started using my first version control tools with Mercurial/Hg after reading Joel Spolky's blog post/love letter to Mercurial. A year or two later I'd go to user group meetups and hear many echo my praise for Hg but lamenting that all the cool projects were in GitHub (and not bitbucket). One by one nearly everyone migrated their projects over to git almost entirely because of the activity at GitHub. I even taught myself git using Scott's website and book at that point!

"Product-market fit" is the MBA name for this now. As Scott elegantly states this is mostly knowing what problem you solve, for whom, and great timing, but it was the "flavor" of the site and community (combined with the clout of linux/android using git) that probably won the hearts and minds and really made it fit with this new market.

Edit: It didn't hurt that this was all happening at the convergence of the transition to cloud computing (particularly Heroku/AWS), "Web 2.0"/public APIs, and a millennial generational wave in college/first jobs-- but that kinda gets covered in the "Timing, plus SourceForge sucked" points

I learned git first because it was already very popular when I decided to learn it. But when I later learned hg for fun, I realized how much of a better user experience it is:

* After using hg which doesn't have the concept of an index, I realize I don't miss it and the user experience is better without it. Seriously, even thinking about it is unnecessary mental overhead.

* As someone who modifies history a whole lot, `hg evolve` has superior usability over anything in git. The mere fact that it understands that one commit is the result of amending another commit is powerful. Git doesn't remember it, and I've used way too much `git rebase --onto` (which is a poorer substitute) to be satisfied with this kind of workflow.

* Some people, including the author, say cheap branching is a great feature of git. But what's even better is to eliminate the need to create branches at all. I don't need to use bookmarks in hg and I like it that way.

I sometimes imagine an alternate universe where the founders of GitHub decided instead to found HgHub. I think overall there might be a productivity increase for everyone because hg commands are still more user friendly and people would be stuck less often.

>imagine an alternate universe where the founders of GitHub decided instead to found HgHub.

I'm reading this as "HugHub" and audibly laughing!

Git really does need a commit header to track the original commit.

> After using hg which doesn't have the concept of an index, I realize I don't miss it and the user experience is better without it. Seriously, even thinking about it is unnecessary mental overhead

... for some people. I know a substantial audience who believe $(git add -a) is The Way, and good for them, but if one has ever had the need to cherry-pick a commit, or even roll back a change, having surgical commits is The True Way. JetBrains tools now even offer a fantastic checkbox-in-the-sidebar way of staging individual hunks in a way that only git-gui used to offer me

I just had a look at $(hg add --help) and $(hg commit --help) from 6.8.1 and neither seem to even suggest that one may not want to commit the whole file. I'm glad that makes Mecurialistas happy

I love surgical commits too. Having surgical commits is extremely easy in hg. You simply specify what you want committed using `hg commit --include` or `hg commit --interactive`. You probably didn't look very closely at the help page.

And if you accidentally committed something that should have been broken up, the user experience of `hg split` exceeds anything you can do with git commands. Quick tell me: if your git commit at HEAD contained a three-line change but each line should be its own commit, what do you recommend the user do? I guarantee `hg split` is so much easier than whatever you come up with.

> You probably didn't look very closely at the help page.

  $ hg help commit
  hg commit [OPTION]... [FILE]...
  [snip]

  commit the specified files or all outstanding changes
  [snip]
   -i --interactive         use interactive mode

Yup, it sure does explain that using interactive mode would select individual hunks, sorry for my "if you know you know" comprehension failure, especially in light of the absolutely orthogonal context of that word used further down the help page you allege I did not read:

   -y --noninteractive    do not prompt, automatically pick the first choice for
                          all prompts

> the user experience of `hg split` exceeds anything you can do with git commands

And yet:

  $ hg split --help
  hg: unknown command 'split'
  'split' is provided by the following extension:

      split         command to split a changeset into smaller ones
                    (EXPERIMENTAL)

without saying what makes it experimental - is that "lose work" kind of experimental?

I still miss hg. I migrated to github years ago because github is a much better workflow, but I miss hg which can answer questions that git cannot.

Reply on news.ycombinator.com