CODEWITHSUNDEEP
gitversion-controlmercurialdvcs
static_rtti
static_rtti

Reputation: 56362

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?

Upvotes: 5

Views: 584

Answers (1)

shellholic
shellholic

Reputation: 6114

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/objects directory. 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 hg log.

      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 log in the nodeid column). To show one raw history entry with id XXXX, type hg debugdata .hg/store/00changelog.i XXXX in a terminal. (look at first line, it will be used later as YYYY)

      The state of the tree is stored in .hg/store/00manifest.i. The corresponding nodeid in the manifest is YYYY.

      hg debugdata .hg/store/00manifest.i YYYY

      This will show a list of "filename+nodeid" appended. Let's choose file foo/bar and note the nodeid appended to it and consider it is ZZZZ (line foo/barZZZZ).

      Last step, access to the content of the foo/bar file:

      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 blobid can collide with a treeid (or commitid or tagid) but that is highly improbable. In Mercurial, a changesetid can 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.

Upvotes: 8

Related Questions