I would like to know what git does better than mercurial.
I would like to know what git does better than mercurial.
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’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.
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.
Easy to customize logs.
Magit exists.
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.
Mercurial logs are also easy to customize.
>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.
Looking for uncommitted changes is what makes it slow. The fsmonitor extension makes it faster. Adding "-r ." skips it.
The "pad" function was added in 2014.[1]
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2014...
Extensions are just how Mercurial commands are implemented. The extensions for editing history are included and supported. The default configuration is just very conservative.