[kccqzy]

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.

[ldayley]

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

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

[cryptonector]

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

[mdaniel]

> 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

[kccqzy]

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.

[mdaniel]

> 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?