mrtngslr

Please see this figure: http://www.aosabook.org/en/mercurial.html#fig.hg.revlog

I hope you see the similarities between the storage layers of Mercurial and of Git: Mercurial has a changeset graph with pointers into a manifest graph. The nodes in the manifest graph points to the files presents in that commit. It's (also) not very complicated.

As for branches, they're very simple too, as I tried to explain here: https://news.ycombinator.com/item?id=6753477

There is only one type of commit in Mercurial. Please don't suggest otherwise.

The commits form a directed acyclic graph (a DAG) and you expand the graph when you make new commits. Subsets of the graph can be said to belong to the same branch (a named branch, the ones you create with "hg branch"). By default all commits belong to the branch named "default".

Any given subset of the commit DAG might have multiple heads (commits with no children), e.g., the subset of the DAG that is the "default" branch might have multiple heads representing multiple features that haven't been merged yet.

To help you pick the right head when you update, diff, etc, you can give it a name — you add a bookmark to the head. The bookmark is just like a post-it you stick on your monitor saying "commit e9ade5b11421 is better known as fix-broken-build". It's just an alias for the commit ID, in the same way that a Git branch name is a convenient name for a commit.

To be useful, bookmarks move when you make new commits. After 'hg update fix-broken-build', a 'hg commit' will move the "fix-broken-build" bookmark so it points to the newly created commit. This is again very similar to how a Git branch pointer will advance when you run 'git commit'.

I hope that helps a bit!

I think the view you present here is outdated. Today, rebasing is used a lot by Mercurial users. Even for the development of Mercurial itself, rebasing is not considered bad, it's considered a requirement for submitting a patch series. That is, the patches are sent by email and applied with 'hg import', and thus implicitly rebased. If that causes too many merge conflicts, you will be asked to rebase it yourself and resubmit it.

Mutating history is front and center in the changeset evolution framework people have been working on for some years now. The first step is that Mercurial tracks when it's safe to rebase or edit a commit: each commit has a "phase" which is "draft" initially, but changes to "public" when you push the commit somewhere. The history editing tools ('hg rebase', 'hg histedit', 'hg commit --amend') will then tell you when it's unsafe to edit a commit.

(OP here) You don't need to tell the rest of the team if you're using bookmarks, just like you don't need to tell the rest of your team the names of your Git branches.

Bookmarks stay local by default, but they can be exported to the server if you like. There's nothing to enable any longer since it's a core feature.