You just need to visualize the tree, and that's it. `hg push -r .` will push checked out changeset and all its ancestors.

Mercurial tracks changesets. Git guys are inventing all kings of weird entities. Local branch? Mutable branch? Do these kind of things have separate sets of semantics in the git world?

In mercurial, branch is just a constant name for a group of changesets. Bookmark is just a temporary pointer to the changeset. Head is a changeset (that have no successors). Phase is information about whether it is safe to modify changeset. Mercurial is indeed a lot simpler.

I think you misunderstood. These "weird entities" that I mention are all part of mercurial. I feel like many of the people who complain that git is too complicated and hold up mercurial as a bastion of simplicity don't really know either of them.

To quote my other comment:

* Branches (named and unnamed) are part of core mercurial.

* Bookmarks are part of core mercurial.

* Multiple heads are part of core mercurial.

* Phases are part of core mercurial.

* Secret changesets is part of core mercurial.

* mq is distributed with Mercurial.

* Local branches is an extension that isn't part of core mercurial, I'll give you that. However, calling it a "third-party extension" is pedantic. It's listed on the official mercurial web site, and using extensions is much more a part of every day usage of mercurial than using extensions in git, for example.

All branches can change, and are mutable in that regard (altough commits can't change).

Local branch == Bookmark with unpushed changesets

All branches and commits/changesets are treated equal.

Yeah. In mercurial you have Branches and Bookmarks. In git you just have branches. Head is the current checked out commit/changeset. Git doesn't allow you to alter commits, only branches, so every modification in Git is inherently safe.

Also, mercurial has mq, which adds a whole extra layer of complexity. Instead of making safe commits, you continually update ("refresh") a set of patch files. Each time you refresh you lose all the history (as if you exclusively used git commit --amend for work in progress). In order to solve this someone got the idea that the patch queue itself could be versioned by creating a second repository that you would commit each revision of the patches to. Unsurprisingly it turns out that two repos are not better than one and doing "simple" things (moving a patch queue between two clones of the same remote) requires fiddly manual operations.

Mercurial has some neat features, but this idea that it's always easy to use and git is always hard to use simply isn't true.

To be fair, mq is needed only for very few specialised needs (apart from strip, maybe). Most hg users can get by just fine with never enabling it at all.

For years the Hg community proclaimed it was the answer to git rebase. Might be time for a concerted doc push to get those references updated with pointers to the rebase extension instead.

Because it was the answer originally (it's wiki page appeared in 2005, rebase appeared in 2008). Then rebase became the better answer. What proclaimed answer are you referring to here? On their GitConcepts[0] page, it says "hg rebase" or "hg histedit" should be used to do "git rebase" type operations. The only time they recommend MQ is if you want the index or the "git am" type command.

And as anton_gogolev mentioned, ChangesetEvolution[1] will probably help augment HistEdit and Rebase for a number of operations. It will allow pushable history rewriting.

[0] http://mercurial.selenic.com/wiki/GitConcepts

[1] http://mercurial.selenic.com/wiki/ChangesetEvolution

> What proclaimed answer are you referring to here?

You answered that in your first paragraph: for many years, the first time people looked at Mercurial the answer for that class of problems was mq. The problem now is that it's still easy to find stale internal documentation, old blog posts, etc. which haven't been updated with the new recommendations. I thought that it might be worth having a small campaign to encourage people to update old wikis, contact blog authors, etc. when they find those recommendations and suggest a simple “this is no longer recommended – see …” update.

Answer to rebase in particular (and the whole "Git makes it simple to edit history" argument in general) is Changeset Evolution [1].

[1]: https://air.mozilla.org/changesets-evolution-with-mercurial/

> In mercurial you have Branches and Bookmarks. In git you just have branches.

I think git branches correspond more to hg bookmarks, than to hg named branches.

Isn't the only real difference that hg branches are constant, while bookmarks are temporary?

Yeah, in hg named branches the branch name is forever logged as part of the commit. Hg bookmarks and git branches are just pointers to the most recent commit.

http://jordi.inversethought.com/blog/on-gitology/ is a good explanation of how git is overly complex.

Or maybe it is Git that has introduced all kinds of crazy concepts that you're now struggling to keep in mind? Local branches? Remote tracking branches? Mutable branches? Really?

You don't have mutable branches in Git, I think he refers to commits mercurial don't allow you to alter (public ones).

Local branches in Hg is the same as bookmarks you havent pushed.

Remote tracking branches in Hg would be bookmarks you have pushed.

Those are all Mercurial concepts.

Well, no. These are _at most_ the names of various third-party extensions, which are not even distributed with Core.

Mercurial itself has just heads, which can be named or not. Bookmarks are orthogonal to the whole thing.

Mercurial without enabling extensions such as mq is simple only in the same sense that quilt is simple compared to git. Things quickly become more complex as you try to actually use it and need to enable extensions to do what you can do with git out of the box. The big benefit that git has over mercurial is that it has a powerful and expressive (and yes, complex) core concept. Mercurial quickly becomes a mess of, yes, orthogonal concepts layered on top of each other.

Anyway, you are plain wrong.

* Branches (named and unnamed) are part of core mercurial.

* Bookmarks are part of core mercurial.

* Multiple heads are part of core mercurial.

* Phases are part of core mercurial.

* Secret changesets is part of core mercurial.

* mq is distributed with Mercurial.

* Local branches is an extension that isn't part of core mercurial, I'll give you that. However, calling it a "third-party extension" is pedantic. It's listed on the official mercurial web site, and using extensions is much more a part of every day usage of mercurial than using extensions in git, for example.

edit: formatting.

Not all Git concepts exist in Mercurial. See more here: http://mercurial.selenic.com/wiki/GitConcepts

He's not saying that they are Git concepts that have analogs in Mercurial. He just listed off Mercurial concepts.