[radarsat1]

> When you don't understand the structure of the underlying database that Git uses

For me this is totally exactly true for Mercurial. I find git's underlying model way easier to understand. Mercurial with its 3 different branching representations (branches, bookmarks, patch queues..) and "state tracking" is really quite a bit more complicated and I do not find it is easier to internalize; quite the opposite, as a git user I have found it extremely difficult to contribute to hg-based projects for this reason. For me, git is just a tree and pointers to nodes on that tree. I find it hard to see how it is difficult to understand.

[hvidgaard]

Branches are, well branches, bookmarks are pointers, and patch queues are quilt integrated into Mercurial, and not something you need to worry about anyway. And if you need to, it's just a staging environment for commits before you publish them to the immutable branch.

I have now, for 3 teams, migrated them to Mercurial from Git, and all now have zero issues with their DVCS. Every now and then, they would write and ask for help with some issue with Git they need solved.

It seems as the average developer do not want to learn the intricate workings of Git to properly use it, and just want a tool that does what you think it will, and will not shoot them in the foot if they issue the wrong command.

[radarsat1]

My point is that you can make the exact same argument in the other direction, so that argument is pointless. Hg users seem to take it as granted that it's so much easier to use and understand but I simply don't find it so. It is not an objective point of view.

Case in point,

> Branches are, well branches, bookmarks are pointers,

you say this as if it is obvious and means something. As a git user, "pointers" are branches, and "branches are branches" means nothing at all. Contrary to claims of Hg users, to understand how branches work I need to spend some time understanding the internal representation of branches and experimenting with toy local and remote repositories to make sure I don't step on my own foot in a real project. Just like I did when I was learning git. The claim that it is somehow more natural and requires less learning is unfounded imho.

> just want a tool that does what you think it will, and will not shoot them in the foot if they issue the wrong command.

I'm sure I'm not the only person who has shot themselves in the foot using Hg. Adding files and changes I didn't intend, pushing them, having to go to the repository site and remove that tip, trying to delete the branch locally to redo things, giving up and re-cloning the repository. These are all learning steps that one goes through using Hg. Just like git.

[hvidgaard]

A whiteboard, draw the commits as blobs and draw arrows between nodes and parents. That is all there is to it. You need to do this for Git as well. This is not an argument for or against. But calling Mercurial branching model confusing compared to Git is dishonest IMO.

The major deciding point between the two is that Mercurial see history as an immutable truth. Git does not, and actively encourage changing it. This is also the reason behind Mercurial "push/pull it all", and Git "push/pull what I say". I believe this is the major point of conflict between the two camps. Once you master Git, you get a tool. Mercurial actively discourage this history rewriting, and many from the Git camp get frustrated that they can no longer easily manipulate what is in the repository.

If all you ever do it branch, commit, and merge, then either are fine. If you want ability to modify history, use Git. If you explicitly do not want to modify history, Mercurial is the better choice. And this is the crux of my point of view. If you modify history in either system, you may end up shooting yourself in the foot. But it's significantly harder to do in Mercurial, exactly because the system encourage not doing it.

[develop7]

> The major deciding point between the two is that Mercurial see history as an immutable truth.

That view is quite outdated[1]. It's true for _published_ history though, but that's it. Couldn't help but note Mercurial did it right, _again_ :)

1: https://www.mercurial-scm.org/doc/evolution/

[hvidgaard]

I was only talking about commits in a publishing repository. What happens on a developers machine, and between developers as draft changesets is quite a different story. We use that a lot and I really like it. Git has the concept of remote removing commits and garbage collection.

[ygra]

I guess you haven't read the link posted. Changeset evolution is not about draft commits that a developer changes locally. It's about actually changing the public, pushed history in a way that nothing breaks for other developers who already based commits on those that get altered.

[develop7]

It's easy to understand, I just don't get why do I need it for anything but Git development. I mean I was perfectly able to be productive with Mercurial without the single shred of knowledge of it's internals. True, I've learned them anyway, but because I _wanted_ to, not because I've _had_ to in order to be able to do anything beyond these 5 commands mentioned in every git tutorial or understand what git output actually means. And, oh, these internals actually are leaking abstractions, multiple episodes. "You had one job" ©

[radarsat1]

> It's easy to understand, I just don't get why do I need it for anything but Git development.

I dunno man.. I don't particularly want to implement a macro language compiler these days, but it sure helps to understand how one works when working with the C preprocessor. (Just a dumb example..)

I mean, are you actually arguing that it should be unnecessary to understand the underlying models that your tools use to do what they do?