3 ms·
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
by hvidgaard 9y ago
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 9y ago> 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/ https://www.mercurial-scm.org/doc/evolution/
- hvidgaard 9y agoI 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 9y agoI 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 9y agoUm, that's not quite true: https://www.mercurial-scm.org/doc/evolution/sharing.html#publishing-and-non-publishing-repositories https://www.mercurial-scm.org/doc/evolution/sharing.html#pub... The limits imposed by phase are not going anywhere; you still cannot edit published history.
- hvidgaard 9y agoPublishing repository by definition contains public changesets. You cannot alter history for them without force. Again, what happens on and between developers can and should be trimmed before it's pushed to the publishing repository.