How can I learn to understand how Mercurial works, as an experienced git user?
I’ve been using git for a while now, and since it is the only DVCS I have ever used, I’ve learned to rely a lot on the way it works for my workflow.
I’m in a new company now, and they use Mercurial, so I need to understand Mercurial’s model and how it differs from git, to adapt my workflow and avoid making costly mistakes.
So what resources can I use for this?
One Solution collect form web for “How can I learn to understand how Mercurial works, as an experienced git user?”
Quite extended concept differences from Mercurial’s official wiki.
Another question from stackoverflow: Git equivalents of most common Mercurial commands?
Comment follow up:
If I resume: “model“, “differences“, “philosophy behind the differences” and influences on the “workflow“. In the differences I can think of, there is:
- For the workflow, except the lack of staging area, you should be able to stick on your old practices (when to commit, when to branch, when to merge,…).
- The main difference of philosophy about branches is that Git clones only the specified branch when Mercurial clones all branches (if you want only one branch, it is possible, but it needs configuration).
- The merge philosophy is not really different. Git can merge two or more heads, but Mercurial can only merge two heads (did you ever merge more?).
- The philosophy about renames differs greatly and each designer did defend his point of view. As Mercurial tracks renames, merge can be easier. Git tries to guess renames at merge time if you use the strategy “recursive”.
Storage differs greatly in implementation, but not in concepts (as you asked for “model”, I will put more details):
Git stores data as “objects” (“commit object”, “tree object”, “blob object” or “tag object”, stored as file uniquely identified by there name which is a SHA1 hash). This is some kind of “filesystem hash table”. With recent versions, those objects can be packed to have less small files under the
.git/objectsdirectory. I will not go further, my understanding stop here as I never found use to know how bits are laid. You can have a pretty printing in the object’s content with:
git show -s --format=raw <commitid> # changeset content git ls-tree <treeid> # list tree content git show <fileid> # blob content
Mercurial stores history of each files individually as “filelog” in the “revlog(NG)” format. You can manually inspect file names under
.hg/store/data(revlogNG). Note that special and uppercase characters are “tilda-underscore encoded”.
You can list revisions of a file with:
hg debugindex .hg/store/data/<file>.i # hg debugindex <file> also works but you see less of internals
You have already noted that the
nodeids are not the one in
And now, inspect the contents with:
hg debugdata .hg/store/data/<file>.i <nodeid>
The revision history (more or less what you see with
hg log) is stored in
.hg/store/00changelog.i(inspect it with
hg debugindex .hg/store/00changelog.i, you will see the same IDs as the one in
hg login the
nodeidcolumn). To show one raw history entry with id
hg debugdata .hg/store/00changelog.i XXXXin a terminal. (look at first line, it will be used later as
The state of the tree is stored in
.hg/store/00manifest.i. The corresponding
nodeidin the manifest is
hg debugdata .hg/store/00manifest.i YYYY
This will show a list of “filename+nodeid” appended. Let’s choose file
foo/barand note the
nodeidappended to it and consider it is
Last step, access to the content of the
hg debugdata .hg/store/data/foo/bar.i ZZZZ
For the differences in philosophy clearly visible from this basic data storage analysis:
When Git commits, it make (potentially a lot of) new files (which can be packed later). When Mercurial commits, it appends to existing files.
In Git a
blobidcan collide with a
tagid) but that is highly improbable. In Mercurial, a
changesetidcan collide only with another
changesetid(ditto for manifests (tree) and files (blob)) which is even more improbable.
- In Git, tags are special objects, in Mercurial, it’s just a list in a file in the repository (with some rules to know which modified copy of the same tag wins).
- In Mercurial, there is no “amend” or “rebase” by default and it is a design choice (philosophy?), always append, never remove content, as it can cause concurrency problem. But it is possible with extensions.