I haven't used hg enough to have an opinion on it, despite several attempts... Problem is I learn bottom up, and I just haven't been able to "think in mercurial" the way I can "think in git".
I find it interesting that what git calls a commit is actually a revision (or checkpoint, snapshot, point-in-time) and what mercurial calls a revision is actually a commit (or patch, delta, changeset).
I think a lot of people think in terms of patches/changesets and I suspect (still haven't gotten far enough to confirm) hg is a toolbox for managing them in a similar way to how git is a toolbox for manipulating its snapshot based DAG.
I find git conceptually simpler, but honestly git and mercurial are pretty close to each other. I've been giving some thought to Fossil recently and it really seems like the industry missed an opportunity to question some assumptions and biases about what our tools should provide. For instance, neither mercurial or git contain issue/bug trackers, but Fossil does.
> For instance, neither mercurial or git contain issue/bug trackers, but Fossil does.
I’m glad git doesn’t. It’s a separate concern and breaks the “do one thing, do it well” UNIX philiosophy.
People can’t agree on a schema for issues/bug-trackers as it is, and you’ll have the ISO 9001-compliant folks who feel compelled to have 150 different hierarchical fields and 20 different issue classes with the Github issue pragmatists happy with only using non-hierarchical non-namespace tags. You could accommodate them all by using a schemaless or custom schema support, but then you’ll have people fighting over how to implement custom schemas, and then having to get people to work on building that feature.
It would also be inappropriate for security-sensitive issues or other cases where compartmentalising information is necessary. (And encrypting the data doesn’t help once the key gets leaked)
If you really want bug-tracking in-repo, you can still do that with a Text-file tree or Sqlite DB in a separate branch (probably a good idea to have a separate checkout to avoid expensive `git checkouts` when the entire tree changes.
Doesn't have two separate concepts for "branches" and "bookmarks" which is extremely confusing compared to the simple Git DAG.
Not having to add crucial functionality like stashes by editing the config to add a new module.
Better UI. For example to get full hash of the current commit, the recommended way to do it in git is `git rev-parse HEAD`. In hg it's `hg log -l 1 --template '{node}\n' -r .` Yes really.
Git's idea of branches confuses a lot of new users. Their expect them to work like Mercurial's. Bookmarks were added for Git compatibility.
The Mercurial command to get the short hash of the current commit is "hg id -i". You can get the long hash by adding "—debug". The "hg log" command shows a more general way to do it and could be shorter.
You'd think it would be `hg id`, but it doesn't work without connection to remote repository and is extremely slow with large repositories with uncommited changes, so it's not the correct answer. --debug option also prints info other than hash and can't be customized.
>Mercurial logs are also easy to customize.
I wanted to customize logging string so that it shows (sequential commit id) - (other stuff), but there's no way to make sequential commit id to line up neatly when it goes from 9 to 10, or from 99 to 100. So making a pretty one-line log is impossible. Maybe it was fixed since then, I wouldn't know.
I thought Mercurial operated on higher-level concepts, such as having branches be first-class objects? In fact, my impression was that Mercurial made it particularly difficult to edit history and required plugins to do so.
Mercurial represents history as a DAG. You can implicitly create unnamed branches and explicitly create named branches. Committing to a named branch records the branch name as part of the changeset.
Extensions are just how Mercurial commands are implemented. The extensions for editing history are included and supported. The default configuration is just very conservative.
I would like to know what git does better than mercurial.