I appreciated the historical context with RCS et al. but I’m left wondering where mercurial sits in all this?
I’m curious about the differences between git and mercurial, are there benefits in choosing one over the other?
I’m curious about the differences between git and mercurial, are there benefits in choosing one over the other?
It is coded in Python, which should have made it slow, but it was very fast. All the data motion and analysis bypassed the Python interpreter.
There was another called Monotone, where Git lifted its data model from, wholesale.
And there is Fossil, which is growing in popularity. If it offered a way to squeeze intermediate edits out of the revision history, it might grow faster, but the author is hostile to the concept. Where it really shines is in never corrupting its data store. I have had Git corrupt its data store quite a few times. By luck, I have not seen it happen on a server others relied on, just on my own cloned repositories. But the tricky stuff is mostly done to cloned repositories.
Are you saying when a private branch is published, it shows up in the public repository as a single diff?
Mercurial has immutable history, so no squashing commits, no deleting branches, at the time I was using it there was no amending commits, in fact reverting a commit doesn’t even come enabled out of the box! Some folks loved it; no changing history, everything documented as it happened. We practiced trunk based development, so no branches except for hotfixes, so there wasn’t a lot of sprawl.
Ecosystems largely don’t support mercurial, so that’s definitely a consideration. Since Merge Requests and feature branches are largely practiced now, I feel like there’d be a lot of noise in a repo if folks used mercurial.
I don’t particularly miss mercurial, personally. I’m less into “pure” workflows and forcing behaviors. I think git is super flexible and generally practical and I’m overall pretty happy with it.
The history editing capability of Mercurial is arguably more advanced than git, especially in a collaborative setting, because of Changeset Evolution [1], and the Evolve extention [2]. The former keeps track of metahistory of commits. The former keeps track of the metahistory of commits, and synchronises it between repositories. The latter provides a set of expressive command line tool to edit history. With them, collaborative history editing and stacked PR is a pleasant experience.
[1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution [2]: https://www.mercurial-scm.org/doc/evolution/
- evolve [0], which allows to rewrite history lossessly (without ever risking losing data)
- absorb [1] which takes uncommitted working copy changes, and for each hunk finds the last commit that touched those lines, and rewrites it. It's an extension originally from Facebook, in core since 2018. Works like magic: no "fix" commits ever more.
Plus, all of this is available using mercurial locally and interacting with git (and github) remotely, via hg-git. Admittedly, this requires to be a bit of an advanced user, but the gains in ergonomics are tangible.
[0] https://www.mercurial-scm.org/doc/evolution/
[1] https://gregoryszorc.com/blog/2018/11/05/absorbing-commit-ch...
>The public phase holds changesets that have been exchanged publicly. Changesets in the public phase are expected to remain in your repository history and are said to be _immutable_
Note that in Git all history is mutable, even if published.
Regarding 'backout' (and 'revert'), to the best of my knowledge, it does not revert commit, it creates a new one (reverting changes), and I frankly do not know is that's possible at all to amend commit in Mercurial (when I worked with it, that was definitely not possilbe, but that was a long time ago)
hg backout is like git revert. Creating a new commit is correct if you want to e.g. propagate the change through continuous deployment.
And hg commit --amend has existed for a long time.
For amend option - well, we switched to Git at time of Mercurial 2.1 (I said it was long time ago), did not notice they added this feature, sorry.
> hg commit --amend
to change the topmost commit.
Marking commits as public is mostly a safeguard against accidentally altering history that others may already depend upon. This is just there to provide awareness of the giant footguns hiding when editing history after it has been shared (git contains the same footguns without safeguards). You can revert the status of a commit from public to draft and then change it. Just like in git, it's very dangerous to do so, but hg makes it very obvious. The command is
> hg phase --draft --force .