Mercurial wasn't the better technology, though. The UX is almost the same as git, diverging in ways that are arguably worse, but the tools were written in much slower Python (initially, and for many years after).
How do you consider the UX "nearly identical" or "arguably worse"?
The Mercurial CLI has clear, well named commands that are predictable and easy to memorize. hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively.
The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, and most people still can't explain it.
I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times.
> How do you consider the UX "nearly identical" or "arguably worse"?
The core concept is similar -- history is a stream of content-addressed commits. Concepts map almost 1:1. git does some things arguably better.
> hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively.
hg histedit is basically identical to git rebase -i. The names are different, but the operations end up being more or less the same. hg amend -> git commit --amend. Graft -> cherry-pick.
> I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times.
I don't know what to tell you. I've also worked with Mercurial for 5+ years, but I've never rm -rf'd a git repo.
> history is a stream of content-addressed commits
Not quite true for mercurial. You also get stable identifiers for commits that remain the same even after being manipulated such as after rebases or amends. It also enables tracking the evolution of a changeset which then enables `hg evolve`.
Being content addressable isn’t a desirable feature in a user-friendly version control system. Who cares about it? Giving stable identifiers to commits is a much more needed feature.
Have you used Jujutsu before? It's git-backed and it sounds like it incorporates a lot of these niceties from Mercurial. I find it an awful lot more intuitive than Git to use and the stable identifiers are absolutely lovely to have.
I've never had much contact with Mercurial myself, so are there any features from Mercurial that JJ doesn't already incorporate? Or any differences you find interesting?
If you tag every commit, sure. You don't know which commit has a bug that needs to be fixed in advance. And at the point you're tagging every commit, you're fighting git.
EDIT: reconsidering: you would have to move a tag when you make changes. A tag is just giving a name to a commit, not a stable identifier that follows a change. A branch is a more appropriate analogy.
A git-native workflow for this would be to have a sequence of branches you continue to update, where 'main' is those branches merged at all times.
git rebase -i drops you into a text editor where you have to manually copy, move, and edit lines, knowing what words mean what and manually type them each time.
hg histedit gives you a TUI which shows an interactive list and allows quick manipulation with the arrow keys and single characters for actions.
I don't know what version of hg you're using, but the histedit I've used drops me into an identical text editing setup as git rebase -i. It includes a summary of what the verbs mean in a comment at the bottom.
Interesting. The curses interface for histedit has been around since 2019, and I had no idea it wasn't the default since it's dramatically nicer to work with: https://www.mercurial-scm.org/relnotes/4.9
> The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, and most people still can't explain it.
I don't know anything about mercurial, but is it really too much to ask of software engineers to understand a DAG (the only "internal data structure" in question)?
About rm -rf ing a repo, I'm sure if mercurial was more popular it would also suffer from the types of coders that would do such things on a regular basis.
> About rm -rf ing a repo, I'm sure if mercurial was more popular it would also suffer from the types of coders that would do such things on a regular basis.
Nope. You are simply flat-out wrong.
I have taught Mercurial to CEOs, secretaries, artists, craftsmen, etc. It just worked. They understood the mental model and happily used it to protect their stuff. The people I taught Mercurial to who worked with CNC machines in particular loved Mercurial as it protected them against changing some wonky setting in their CAD program that screwed everything up that they somehow couldn't figure out how to restore.
Git I can barely even explain to CS majors. The fact that AI has so much training data and is so very, very good at explaining how to undo strange Git states is all the evidence you need for just how abjectly terribly the Git UX is.
Jujutsu has proven that the underlying structure of Git is acceptable and that the issues really are all about the UX.
Well I can explain git to anybody who understands a DAG. And mercurial is also based on the exact same data structure. So yes it would be very surprising if you didn't consider it to be "acceptable".
The fact that there's lots of training data out there on strange git states is proof of exactly my point. Git is popular and thus used by lots of people who don't know the first thing about the command line, let alone data structures. Had mercurial won you'd see exactly the same types of errors commonly appearing.
You can get by with `hg next`, `hg prev`, and `hg rebase -s <from> -d <to>` to move entire chains of commits around. Commands with obvious names that allow moving around without understanding chains of dependencies. No weird states where you checkout an old commit but random files from where you just were are left in the directory tree for you to deal with. No difference between `checkout`, `reset --soft`, and `reset --hard` to remember. No detached head states.
And no, `HEAD~1` is not a replacement for `prev`. One is a shortening of "previous", one requires you to remember a magic constant based on knowledge of the DAG.
Look, I'm not commenting on which system has better named commands. My main points are
1) A DAG is not a difficult concept to understand (despite the "scary" name). If you can understand package dependencies or a manufacturing process you already understand it.
2) Learning git without knowing about the DAG, i.e. knowing what a commit even is, is counterproductive. It's like learning to drive a manual car without knowing what the clutch does. Sure you could probably teach someone that way, but why would you? What's the benefit to learning mercurial without understanding what a rebase actually does?
I disagree that Mercurial users can use `hg rebase -s ... -d ...` without understanding a DAG. The mechanism is only meaningful if you understand the structure of the commit graph.
If I spend a couple hours reading I can understand how git works, but I'm going to forget an hour later because it is so damn complicated with all the different details that my brain flushes it's cache to make room for something with less violently confusing edge cases.
For understanding git internals I went through "Git from the bottom up", a simple document with examples you type in, just to see what's going on. Many of those examples are raw git commands, nothing as sophisticated as "git commit". Easy to read, doesn't take long, but leaves behind an understanding that isn't maybe fully obvious at the time but makes everything much easier, forever. I've recommended that method to many coworkers and it seems to work well for most people. It doesn't need hours of reading either.
> Well I can explain git to anybody who understands a DAG.
This. Right here. This is the difference.
I can explain Mercurial to people who don't want to understand a DAG.
For non-professional developers, the "merge machinery" is completely worthless.
The difference is that Mercurial lets you duck it until you need it while Git slaps you in the face with it at every commit.
For the non-professional developer, the flow is "commit, commit, commit, commit, whoops--how many commits do I need to go back to fix things?, oh, 2, okay--revert, commit, commit, commit, commit, ...
At no point in their day are they facing "merge". And that makes all the difference.
The non-professional flow you described does not require merging in git either. I suppose most teaching resources about git go deep into merging because it was created for distributed development where that's important, but it doesn't mean you have to teach it to a non-professional like that.
Not that I think mercurial didn't have "simpler" UI back then, but the arguments thrown around in this thread are pretty bollocks.
> The Mercurial CLI has clear, well named commands that are predictable and easy to memorize.
Precisely this. I've been stuck using git since 2010 and to this day I have a large git-cheatsheet doc which I need to reference any time I need to do anything beyond the daily add+commit+push. The git commands make zero sense and are just about impossible to remember because they make no sense.
In contrast, I've never felt a need for a cheatsheet doc for mercurial commands.
> done rm -rf to start anew. Every single git user I've talked to has done that multiple times.
Indeed! Of all the source control tools I've used, git is the only one where I regulary need to do a tarball of the src repo before doing any uncommon operations because there is a non-zero chance it'll go into some unrecoverable state and need to start over.
I've never rm-rf'ed a git repo (why would you voluntarily remove the reflog?) while also being a very mid-tier developer. The types that do also tend to reboot machines every time something goes wrong instead of looking for the exact cause of the problem and fixing it once and for all; to screw around with SQL (move subqueries here or there, add and remove indexes at random) until it runs acceptably instead of building proper understanding of how their database works, and so on. At least judging by what I've seen. Not really something to be proud of.
I thought it was enormously better because it helped you not to cut yourself with all the dangerous things in a way that git didn't. It also had an excellent GUI (thg).
It was a much less stressful tool to use and git hasn't really got much better since then - I've just converted a repo to git and the team using it have had about 4 unpleasant mistakes in the last week as they adapt.
As for speed.....I cannot say I ever noticed any problem. Waiting around for the version control system has never been an issue for me.......except a git repo with 70,000 commits and we worked out how to merge a lot of those to fix the problem.
I upvoted because even though I prefer Mercurial I do like tools that are powerful and flexible.
The problem for me is that VCSes have a mental model and the way they actually work is more complicated than that. I haven't tried to deeply understand Git and in a way I slightly resent needing to - even Mercurial has the same problem in some areas but there it's more about a feature I want and the oddly contorted way they achieve it (specifically bookmarks) and it's not a situation where I get into danger and don't know how to get out.
Branches are great. I don't want to know that they're "just a pointer". :-D I'm so dull that I never use the "staging" concept because it's just a huge opportunity for making mistakes (for me). I really want something simple to reason about where I can add little complexities if I need them.
To take the bad Mercurial example - I don't really need permanent branches and I definitely don't need some new concept with oddly different commands to give me impermanence. Let me delete a branch!
Can any of the downvoters comment on this? My experience with Git is pretty much the same, but maybe Hg also allows you to unfuck a screwed up repo, just as Git does?
The bad states Git "allows you to unfuck" are largely caused by Git's awful UX (confusing and multipurpose commands based on inner workings), so Git gets no credit for "solving" a problem it caused.
Writing your tooling in python is valid while starting out and prototyping.
One of the big criticisms I've seen levied against Rust is that refactoring is extremely difficult, so prototyping on ideas in the language itself is a poor experience.
I've personally had great success using python, then gradually rewriting the tool I have with py03 to "oxidise" the program iteratively.
Starting with C was great for performance of Git, but damn if it's not a terrible UX these days, I can believe that the choice of toolchain and language was a contributor to that fact.
The Mercurial project has been incrementally rewriting core operations in Rust for several years now. As Pierre-Yves says in the talk, you can do an hg status on a million-file repo in 100ms. I rewrote hg annotate (aka blame) in Rust last year.
It's kind of late, though, right? Git had core components ("plumbing") in C from 2005, with gradual rewriting of the "porcelain" layer from Perl to C in the late 2000s and early 2010s. People have been complaining about Mercurial performance for a long time. I'm sure the Python 2->3 headache did not help.
While I agree that Mercurial probably lost a ton of users for not clearly addressing performance issues for quite a while, I've found it's never too late to switch from using git, to be honest. I am personally using Fossil for all of my projects and it's been a great experience overall. I didn't have particularly challenging needs when it came to git so I wouldn't say that it's been a major headache overall for me, but I also think Fossil just is better as a default than git for everything that I do (and everything I've ever worked on):
- Assume we want to sync to main repo as a default when issuing operations, keeping us in sync more often and easily
- `commit` just commits all indexed files with changes, no need for staging
- Worktrees by default (admittedly this is more of a convention and you can certainly do the same with `git worktree`, but it's very prominent in how they show you how to use Fossil).
- `fossil ui` for having your own mini-GitHub is great, and having changes you make there sync with your remote is incredibly convenient.
- `fossil serve` on your remote is a great way to make your mini-GitHub an actual persistent service. I've used SSH remotes for `git` but as far as setup goes this actually is a close second in terms of convenience. Nevermind setting up a more involved forge; `fossil serve` is overperforming for what you get by a lot here.
All in all switching to Fossil after a ton of time using git has been a great experience overall.
I’ve never met a single person who can use git to move a commit and its descendants from one parent to another. This requires using the extremely unintuitive `git rebase --onto A B C` invocation. The only exception are magit users who are dealing with a much better interface and a better name (magit calls it rebase subset rather than onto).
In contrast every single mercurial user I know can intuitively use `hg rebase` with its `-s` and `-d` flags. That’s one giant difference in UX.
You need to say “ i’ve never met anyone who could do that in one single command line invocation”. It’s trivial to separate that result into two or more steps using bare primitive git commands and perhaps a temporary branch. You don’t need to memorize every esoteric flag if you understand the fundamentals and don’t mind spending 15 extra seconds to execute multiple commands
Okay so the same operation with git is an esoteric flag but it’s easy in mercurial. Got it. Which has the better UX then?
> It’s trivial to separate that result into two or more steps
Okay first, tell me how to separate it into two or more steps. Second, tell me why a single operation in a user’s mental model needs to be split into two commands. The user is thinking about moving a commit and its descendants from one place to another; why should this seemingly atomic operation be split.
> This requires using the extremely unintuitive `git rebase --onto A B C` invocation.
Unintuitive yes, and I'm not going to disagree with you on UX, but it's not a particularly difficult thing to learn if you use a rebase centric workflow and this is a command I use daily.
P.S. don't forget to use --update-refs (or add to your .gitconfig) ;-)
I think the way I would do it, is to go to target branch, cherry pick the commits and push. Then go to source branch and revert the changes. All done from within the IDE. Not the cleanest way, though.
Incredibly common when you write code faster than your colleague or manager can review them. You always have lots of branches and sometimes the branches implement interrelated functionality.
I've used git and mercurial for roughly the same amount of time.
Your statement is, frankly, something that makes me question your sanity. They're not remotely similar. Outside of something like Perforce, I've not used a VCS with a worse UI.
The Mercurial CLI has clear, well named commands that are predictable and easy to memorize. hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively.
The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, and most people still can't explain it.
I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times.