Almost 20 years ago I helped our company choose between Git and Mercurial as the replacement for Subversion. Unfortunately, I helped them make the wrong choice, Mercurial.
I say wrong because clearly Git won the war and I haven't used Mercurial since then. However, I still think I made the right choice from a technical perspective; I thought Mercurial was way more user-friendly while providing all the features and performance needed. But I guess I couldn't read the future in terms of which one would win out!
Mercurial is one of the many sad stories of far better technology being forgotten by the popularity contest juggernaut of something else.
I still use mercurial for all my personal project where I don't need to care what anyone else thinks. It is pleasant to use good tools, just like I like to buy top quality rachets or such.
Can't comment on Mercurial, but "for all my personal project where I don't need to care what anyone else thinks" I am using Fossil. Ever since that decision, I've felt a bit, well, held back, or rather, I don't feel quite as comfortable as I do at home when I have to use Git.
If you're talking about binary files, then it has similar limitations to Git and Mercurial, AFAIK. Fossil, git, and Mercurial are not really designed for large binary files.
Otherwise, in Fossil, any text is just another artifact. Wiki pages can be stored as files in the repo ("embedded") and versioned in the same manner as code files (that is, exposed through the same interface), or tracked behind the scenes (in a separate database, IIUC, with a different interface). Tickets and forum entries are also tracked and versioned similarly to non-embedded docs.
Aside from everything being versioned, the visibility of the objects is quite good. The user interface, both command and web, is light-years better than anything Git related.
I highly recommend you check it out. Even if you find it doesn't meet your needs, many of the design decisions are instructive. I find it quite inspiring.
I'm like the person you responded to, I've just used fossil personally for years after working at a place using it a while back and always liked it.
This is its moment though. It is so well suited for LLM coding tools. You can jam all the markdown context, skills etc into the wiki. The CLI has wiki and ticket tools so those are just available for it to use. Fossil does not mind if you use the repo DB for your own stuff, so you can log all your sessions in there, fts5 is plenty for as needed on demand retrieval.
Big changes to professional development over the last year and hard to predict how it will all shake out, but I think the tooling will converge on something that fossil already has all the structure for. I was a late adopter on LLM-assisted coding but already feel ahead of a lot of my peers because of how easy and effective this approach is.
Is git really far worse technology than mercurial? I’ve used both for years and to be honest they are pretty similar. What important capabilities does hg have that git does not? Maybe you can argue that hg is more ergonomic, but that’s just polish it doesn’t mean the tech is far better…
If you think about how much investment has gone into Git, whereas Mercurial has really been developed by a skeleton team, even the fact that they’re similar is indicative that Mercurial may have been better at its core.
I haven’t touched mercurial in like 15 years, and from what I remember its UX was superior to what Git provides today. It had an extension system which I don’t remember the full capabilities of so I don’t know if Git has even now matched up to that.
> Is git really far worse technology than mercurial?
Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it".
In addition, Git's UX is hot garbage. I would constantly be doing rsync on git repos before any operation that is slightly weird knowing that I may put the repo in some state that I cannot easily unwind. I never did that for Subversion. I never did that for Mercurial. I don't do that for Jujutsu. Those are all sane UX.
Side note: Thankfully AI is REALLY good at telling you how to un-wedge your git repo. That should tell you everything you need to know about Git UX and why you should avoid Git.
> Most people on small projects just want "checkpoint the current code in my directory and put a comment on it".
Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the exception?
My use of `git add` - and the explicit staging area more generally - is mostly a workaround for the fact that the repos I work with have checked-in dev setup scripts, IntelliJ/Visual Studio/Xcode/VS Code configurations, and so on.
My own setup differs in slight ways from what those scripts expect, and even where they match I like to do my own customizations. I don't want to commit those changes, and staging makes it easy to not do that MOST of the time. The rest of the time, it's a `git stash` dance, which I sometimes screw up and lose the customizations.
I've tried to manage the configurations a different way, such as by having a private branch with my own settings checked in, but that doesn't usually work out. I'm aware that the REAL problem is that my coworkers have checked in those settings to begin with, but I would counter-argue that the REAL REAL problem is that those tools don't have a good way to combine "settings that I override or that only I care about" and "settings that have project-wide defaults but are safe for me to override." (Visual Studio gets it close to right with its .xyzproj and .xyzproj.user files, but VS Code's single .vscode/ folder breaks down in shared repos.)
If you feel like fucking around with new source control tools, jj (jujutsu)'s megamerge workflow is really good at this.
(If you're not interested, feel free to skip the rest of this).
I have each in process workstream in a commit that is merged at the top level, then I have a new wip commit off of that where stuff I'm typing right now sits.
It's easy to split/squash/absorb parts of that commit into the right destination, but also to introduce parents of the megamerge that will never get merged.
People make this claim but it never made sense to me. How do you know the version that you are committing is buildable if you never tried building with it? And if you tried building with it, you can just do `git add .` or `git add -u` at that point.
So yes, your usecase does not make sense to me.
There was another comment that said similar thing...
1. Not a very good reason. Some projects might have slow CIs. Some projects might not have a CI at all. Some project's CI might not be checking everything (front end for example)..
2. Because people make mistakes. You might think you are only excluding a comment, but might be excluding something that is required by mistake.
When I really want to do your workflow, here is what I do. Add all the debugging print statements and commit them separately in another branch. When I want to include the debug statements, I just cherry-pick the commit with those things.
This way I remove the overhead of doing a staging before every damn commit and still retain the ability to pull in debugging changes whenever I want them.
>Without CI, how would you even know if your projects compiles on other platforms?
Not everything need to be cross platform! And not everything need CI..
This sounds more complicated overall. Also, I would still need the staging area to only commit the debug statements.
As I said, I like to work on several things in parallel and I don't want to switch branches back and forth. That's just my workflow for my own projects and apparently I'm not alone.
To be clear, Mercurial does not have a staging area, but it does have allow selective commits (and selective uncommits) via prompt-based or interactive UI selection of hunks. Disagreeing with the need for a staging area is not the same as saying selective commits are unnecessary (I use Mercurial more than git and I rarely commit everything in my working directory in a single commit - I like small commits).
When there's an expectation or requirement that each commit builds (and even passes tests), how can you do partial commits? Do you work exclusively on projects without such requirements? Do you rely solely on CI to ensure that your commit compiles? Do you not use CI and not care if a commit is broken... you'll squash a fix in later, or not even squash it and leave a broken commit in the repo?
Why would partial commits necessarily break anything?
In fact, often partial commits are necessary for builds.
As an example (and to be fair, this was a transitional project), I once worked on a project where the local dev directly acquired packages from different parts of the application, but the actual CI was broken up into different pipelines which required some parts to be built first, its outputs packaged and added to the registry, and downstream parts to be built after.
Committing everything at once would literally break the CI.
If the dev's working tree isn't exactly what they checked in, how do they build or test the commit? Do they YOLO a partial commit and wait for it to be accepted or rejected by the CI? Isn't that a problem to be solved by improving the CI pipeline?
I'm with you. My current code is a superset of the task I'm trying to accomplish, test code, leftovers from experiments, etc. I often have to break it up into logical chunks that get merged separately. I tried the jj flow and it's just not my thing. Git matches my mental model exactly, but I used it second (after subversion) and in my most formative years as a developer. Maybe there's a universe out there where things worked out differently.
Same. I absolutely don't use git for snapshotting what I'm currently doing. That goes both for work and for my numerous hobby projects. I always cultivate commits so that they're focused on a single type of change or feature, and then the next commit is typically something which uses that feature, etc.
I don't mix in whatever else I'm doing - be that whitespace changes, update comments elsewhere, or other features I'm working on.
This helps tremendously when (as I do) I leave my hobby project for a while and then I come back months (or sometimes years) later. And, both for work and for hobby stuff, if I want to add something, e.g. support for a new function, and I had done something similar in the past, it's easy to look at the particular commits about that from the past, and I can see that I need to update this, this, and this file so-and-so, and with these kind of changes. I don't have to wonder about what belongs to this feature and what doesn't.
Oh, and I use git add ---patch almost exclusively. It's rare that I just do a "git add". I'm building up my stage, I'm checking it, I'm fixing it (if I accidentally stage something which doesn't belong), then I commit.
Having done it like this for a great many years I'm benefitting from it all the time. I can look at all my hobby projects (looking at the commits), and I'm back in where I left off, and I see excactly what I was doing back then (which, obviously, I wouldn't be able to rembember otherwise).
CVS though.. that was harder to do right. So a lot of stuff became just snapshots. You had to plan much more carefully. And then there was SCCS before that.. and before that again, well. Manual "keep two versions" svc.
I don't see why there has to be a special staging area when you could just edit the HEAD commit instead. In git you could do "git commit --patch" to commit selected parts and then add more changes to the HEAD commit by "git commit --patch --amend".
A normal situation in my tasks is when the working copy contains lots of changes that are used for debug (mainly prints) but these changes shall not be committed to the proposed change. For this, even interactive adding (`git add -i`) does not satisfy; I need `git add -e` which allows editing in a patch form, and remove the temporary local changes.
Git add is a reflection of git commit being such a heavy operation.
It’s a pointless addition. Making commits easier to modify and undo would eliminate any need for git add.
But git can’t really do that since it’s so fundamentally based on the idea that commits are immutable. Any modifications r does allow are workarounds, and dangerous ones at that.
The way I do things is that there is no such thing as a shape that can't be committed. Committing is just like saving. It's fine to commit haphazard checkpoints and all manner of crazy stuff. You can use tags or merges or whatever to indicate that something is "done" but for me those kinds of commits are the exception, not the norm.
Supposedly, Meta has the data to support the claim that you (and I) are the outliers here. Staging is confusing to users, especially new ones, which is why jujitsu explicitly doesn't have staging.
Both things can be true (the second being that staging was never necessarily not a desirable abstraction in light of easily and safely amendable commits)
With “git reflog” and “git reset” or “git checkout” one can undo any series of ill conceived squash/rebase/amend operations. There’s actually no need to rsync the work area in advance.
Try doing the same in any other source control system…
On the off chance that you haven't already had this suggested to you on HN, I would suggest taking a look at JJ.
I use it in all my Git-underneath repos with `jj git init --colocate` (You can run that in a git repo and it will hybridize, or in a new folder and it will init and hybridize).
It doesn't have the staging concept, treating the working copy as just another commit (@), and to boot it snapshots the state of the tree into @ when you run any jj command, so you can use `jj op log` to see every intermediate state of your working copy at any time.
Commit is just `jj commit` with no staging mechanics, or `jj split` to 'split the working copy commits' (commit some, keep the rest in @).
Mercurials lack of not permanent branches early on with the bizarre "we have a plugin for that" way of doing it showing up too late to change the decision
not to mention the early "just clone it into a new dir" answer before lightweight branching ...
I often want to "save" but not have a comment, and not ready to make it a clean commit that I want a comment on. That's when I stage, then I can see the diff and revert still. But ya, maybe I could adapt to not worrying about having a million commits instead of clean ones at points that make sense with good comments.
A good way of thinking about it is that every commit is itself version-controlled, allowing unlimited edits. This even allows two people in an evolve-enabled repo to make changes to history at the same time, and Mercurial will resolve any conflicts. It makes it trivial to commit (and even share) a "WIP" commit which you can later amend/split/whatever. It's different from git where you basically can't edit history after pushing (in Mercurial this only becomes true if you push to a non-evolvution or "publishing" repo, where everything then gets squashed for public consumption).
You can add everything and commit all at once in git, so you’re technically using staging but it doesn’t feel like it.
I stopped using it the first time I committed something I didn’t want to, over a decade ago, haven’t used it again since so I forget the exact invocation, but I think it was just “-a” or something.
Before it bit me though yeah, that did seem like a default I’d have preferred. Not any more.
I haven't lost data to git in a long time and I never rsync anything. But it took a long time to get to that point.
Git is extremely predictable, but only after you thoroughly understand it. Until then, it seems to surprise you often and every time it happens you think you've lost data. Many times I've had collaborators who said "git ate my files" and I can usually get their files back in a few minutes. This makes them hate git because they cannot use it without having me on call, and they cannot be bothered to learn git thoroughly themselves because it's too damn hard.
I've always felt bad about not understanding git better and wanted to dedicate time to learn it properly but never got to it. Finally this is a use case where AI is really good. It has always been able to get me out of trouble when I mess up, and often rescued files I thought I had lost for good. And is always able to rebase for me, normally a place where I flail pathetically. And it's easy to human verify the result before pushing.
Honestly this is one area I really like AI - so I can focus on the things I really need to focus on and not spend a bunch of time becoming an expert in things I don't want to be an expert in.
The best recommendation is "Git Internals" (https://github.com/pluralsight/git-internals-pdf). It teaches you how git works from the internal, and give you absolute confidence and understanding on how the tool works.
I guess it'd take one day of your life to read it, but I think it pays back a lot.
This was indeed one of the sources I read to become a git expert. Git is simple and elegant on the inside. Which you'd never believe if you only studied its UI.
I find staging useful even in small projects. I've been deliberately experimenting with jujutsu for the past year or so in various projects, and one of the workflow differences that I noticed most readily with jujutsu was the lack of a staging area. It took me a while to get used to that.
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.
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.
Correct. The comparable git workflow when you fix a bug is that the work goes on the branch of the feature the bug was in, and "main" is updated to use the new head of that branch.
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.
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.
> 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.
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.
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?
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.
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.
> 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.
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.
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.
Mercurial had an easier to use command line interface. If that's what makes it far better technology, we have a very different idea what makes the "technology" better.
My recollection is that it was more of a VHS vs Betamax story than one being strictly superior. When a lot of people were making their decisions, Git was a lot faster in ways that mattered. IIRC, shortly after a lot of places picked Git, Mercurial cut a release that significantly improved performance.
I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects, and that is changing given the sad state of GitHub.
Another contender is Jujutsu (jj) which allows you to use jj as frontend and use Git as the backend (with the potential to support any backend, e.g. Google's proprietary Piper), with the best ergonomic and the widest availability of hosting solutions.
I’ve recently switched to jj and it is truly amazing. It too about a week for me to “get it”. The tool is amazing but I think there’s way too much emphasis on what it does/allows rather than what benefits it brings to your workflow. If they get that marketing right I could see it growing. If not, I’ll keep using it
jj is amazing, even as a solo dev on small projects. It's difficult to explain because it depends of each usage, but it's very easy and safe (you can undo everything) to just try and see.
> I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects
Nah. At the time BitBucket was the better way to do open source projects, and they were Mercurial-first. But eventually they had to add Git support because there was so much demand.
I'm glad that I stuck to git for a similar reason; it won the war. And I understand the need for simpler tools.
But to offer a point I haven't heard from anyone before: at least I feel that I am done with it, I learned this tool sufficiently and I can move on with my life. From time to time I add something to my git toolbelt. I feel if Mercurial or anything else have won, I would maybe have to learn another tool in 5 years, whatever else got popular, and another in next 5 years. But now I have everything I need in git, and always have needed. I hold some hope in it that perhaps the learning curve was worth it.
I’m glad there is one clear winner and we’re not in the common position of having 2-3 relevant/semi-relevant choices that you’re frequently asked to switch between depending on which project you’re looking at at the moment.
Git is modern version control, whatever you think of it, and there’s a simplicity to that.
Despite not using anything else, I don't know all the git commands I need to get my job done so I use UIs and my agent. It's just not intuitive enough, some things are just not possible to do right, and I look forward to ditching it.
But I agree: Mercurial was definitely friendlier for people who didn't have time time to go through the technicalities of git. To use git smoothly you pretty much need to learn how it works internally.
Then you made the right choice, and it's only unfortunate that not enough of you made the same to tip the scales in favour of mercurial, or at least to avoid the monopolistic situation we are in now.
I might say that I stopped thinking too hard about this many years ago: now I use hg-git whenever I must interact with git, but do regret that the more sophisticated/qol features of hg (branches, evolve, phases, topics, ...) don't exist in git, and that's the real bummer: the more limiting alternative won, then stagnated, and we are all worse off as a result.
I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling. But it was not all amazing: Mercurial’s branching model was very poor, and its sequentially numbered revision system was and remains a very bad design.
I think I liked the Mercurial branching model better than git, due to the branches being a first class record of events. What I did not know is how common the git rebase/clean linear history would become or a desire to change history on merge.
Mercurial had bookmarks that were roughly the same as git branches.
The linear version numbers were quite useful to reason about and use in places that call for a "number" version number, and were useful relative to your "master" clone. That was not the primary way though, it had hashes like git too, that were the same from clone to clone.
The branching model being keeping a record is fine, but needing to make up a name for your branch before committing (unless you like rewriting) was not awesome, and the names being a global namespace was unpleasant.
And then, when you pull someone else’s in-progress work to inspect it, you end up with their branches showing up with their names and you ended up with revisions 13564-13592 belonging to someone else and showing up in your history graph even when you continue on your own work at revisions 13563 and 13593. I ended up using temporary clones and strip a lot.
git branches, in contrast, are delightfully unobtrusive.
The clean linear history thing is something I never really got, despite using git for 12 years now. I worked with some smart developers whose rule was "rebase if you want, but if too complicated, just merge", and it didn't hurt the delivery or maintainability of the code they wrote.
Yes - whenever I'm in a team and I hear someone who insists on a linear history, I always wonder why they have trouble with merge when lots of folks like me have no problem with it.
Finally, in one team, I more or less forced a senior engineer use merge (or rather, I was in control of the project and did not force other developers to use rebase). After a year, he admitted that he no longer really saw a benefit in rebase and switched to just using merges in his own projects. He also noticed fewer merge conflicts this way.
Rebase makes sense when you realize git doesn't have branches. Git has tags that move but no branches. That means when you merge you have no clue which branch was the mainline and which was the fork. This is a question I often ask 10 years after switching to git. Sadly git has better tooling so it is worth using despite the issues.
> That means when you merge you have no clue which branch was the mainline and which was the fork.
You mean - when looking at the history?
Incidentally, once you get used to jujutsu, you realize that the question is meaningless. A merge is simply the child of two nodes. It's a symmetric operation between the two branches. The thing that makes it "complicated" in git and traditional VCS's is the insistence in assigning a name to the resulting merge (so if you're merging into main, you want to call the new node "main"). Since jujutsu doesn't automatically carry the name forward, you see the "reality" of merge being a symmetric operation (i.e. you don't merge a branch "into" another branch - you are simply merging two branches).
That is exactly my point. I'm not merging two branches together. I'm merging two branches with very clear different meanings together. One of them is our main line, one of them is a feature branch. Everyone talks about all you should develop in main line, and I certainly encourage that. However, often that just isn't practical in a large project for various reasons. Some of them aren't even good reasons, but nonetheless that is the reality.
For a complicated long running feature branch I can see it. Instead of repeatedly merging the root in during development it can be cleaner. Tools aren’t always good at figuring out in a PR what was written and what was caused by those merges from root. And history looks better at the end.
For a short branch that can merge cleanly or perhaps very close to it, I’d kind of rather have the ‘true’ history. I don’t think it’s worth it.
I’ve never understood the “everything must be rebased before every merge” desire.
It really depends on how often you use git bisect and blame. This varies greatly across projects.
That said, if/when stacked PRs become a first-class citizen in GitHub, more projects will see the benefit of this approach (though they'll probably mostly get there through squash-merges).
The way I remember it was that bookmarks were added because the git branching model became so popular. The "branches" in Mercurial were allegedly not designed with short-lived feature branches in mind.
Sequentially numbered versions is still used at main Google monorepo (at least did a few years ago), named "changelist number", from perforce. Up to the point that people define extension field numbers in protobufs using their changelist number, to ensure it will never intersect with anyone else.
I always hear it has far better “tooling” but then the comments say that branching sucks, revisions suck and there is no good got stash equivalent - this is like a third of what I use daily with git.
What does “far better tooling” mean exactly, could you give an example of what amazing tools I’m missing out on (never have used anything else but git, when I came to the industry it was already the standard)
Branching in Mercurial is as good as or better than in git, but it takes a few minutes of additional reading until the full flexibility of Mercurial's model actually reveals itself. Revisions can be safely ignored in favor of commit hashes. I haven't used revision numbers in hg for at least a decade now. And hg has a stash implementation that is on par with every other VCS that I've used so far.
TortoiseHG is a very good client that covers all common Mercurial operations and then some. It's on par with a couple of commercial git clients that I've used. On the server side, there's e.g. heptapod as a GitLab fork that has a deep Mercurial implementation.
When I used it a decade ago, virtually everything in mercurial was slightly better-designed, more user-friendly, and more polished. Much shorter learning curve.
Gotcha - most people here probably use git for more complex stuff - I almost exclusively use the same 20 commands for my daily work and wrote a cheat sheet for them ages ago (I mostly memorised it by now). Occasionally i need to ask an LLM for some help but that’s maybe once every few months.
Meh. While I agree that Mercurial had easier to use CLI, there was maybe 1 time over the last 15 years or whatever when I needed anything other than git reset --hard.
Although, I suppose part of this is just that manipulate index with something like lazygit.
It means that git invented a bunch of new jargon and ideas that confuses people exposed to it for the first time, where hg's usage metaphor hews closer to the received wisdom of people coming from stuff like subversion and perforce.
It's true that git's ad hoc command line UI isn't exactly it's greatest strength. But given the complexity of the design space here that's a pretty weak argument IMHO. The two weeks it takes to get the basic git workflow into your muscle memory pale in comparison to the years it'll take you to be good at bisection and tree maintainership.
It's also sort of a wrong argument in the modern world. People new to git have extensive assistive technologies available. There is, after all, no HgHub out there.
> I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling.
I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches, of even we could perhaps install a module such as shelve.
That was the image that Mercurial left with me with regards to git: missing critical features and not bothering to bridge the gap.
> I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches,
I started with Mercurial, eventually got forced into git, and now use jujutsu.
Totally agree with the Mercurial developers: Just use a branch/bookmark. When I encountered it in git, it seemed neat, but became yet another concept/thing to clean up that you don't need to.
And lo and behold, after switching to jujutsu, everyone shows how you can do a stash using an (anonymous) branch.
Even though I used stash a lot in my git days, I don't miss it at all while using jujutsu. The benefit of jj is the ease with which one makes branches (without needing to name them). That's why you may not have liked the advice in mercurial - it wasn't the solution that was problematic, but that mercurial didn't make it as easy as it should have been.
(Same goes for index - no one misses it once they switch to jujutsu).
> Even though I used stash a lot in my git days, I don't miss it at all while using jujutsu. The benefit of jj is the ease with which one makes branches (without needing to name them).
This topic is not about stashing though. It's about UX and providing first-class support for a basic use flow. If git stash was an alias for creating a branch and committing local changes to it, the point still remains: the problem with Mercurial was how it went way out of their way to argue against supporting features that users actually wanted, and supporting it as a first class feature.
And to me that's why ultimately Mercurial was bound to be forgotten while the tool that met uses' needs attained the status of de-facto standard.
The same can be said about other major features such as support for large files.
To top things off, the way that git maintainers have been actively adapting to feedback from jujutsu's users is yet again proof of why git still remains the de facto standard.
It did have a kind of equivalent to stashes in the mq extension, but its interface was a bit esoteric compared to the rest of Hg, from what I remember.
A lot of features that git had by default had to be enabled as plugins in mercurial.
The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off.
I think some of the extensions were very basic stuff like graph logging and colorized output -- and mq like you said. So it was kind of unfortunate that people got a bad impression of hg from that and bounced off.
git rebase, for all its warts, was always better than mq. A failed mq-driven rewrite was destructive! (And it kind of had to be — if you were trying to edit revision 17, there was no number available for the original revision 17 because the schema didn’t allow two revisions numbered 17, so the original had be excised.)
- Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.)
- Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model.
- (It had a third major advantage over Git that I unfortunately cannot recall at the moment.)
So you weren't wrong back then...
...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.
That's a matter of taste. I used both for serious work, at the time, and found Git much more usable. My experience with Mercurial was "welcome to Mercurial, how can we help you merge and push your work in progress even though that's not what you want?" My experience with Git was one where I felt in control at all times, had a clear workflow for when I did and didn't want to publish my changes (and for when I wanted to edit them first), and allowed me to quickly make and switch branches within a single working copy.
Thank you. I vaguely remember being put off by Mercurial at the time and feeling much more comfortable with git, but couldn't have put it into words as well as you did.
People always say you have to know git internals in order to use it, but that's just not true. Git has the right data model and has always been about empowering users to edit their data. Which makes the data model be "in your face" compared to the alternatives (and I think that's what people latch on to when they talk about "internals"), but it ultimately makes for a better tool.
I don't think the internal design is/was that similar. We switched from CVS to git, and were evaluating multiple choices. What tipped the scale in the end was our trust in the internal data model, which for git was the idea that it stores the snapshots, and they are immutable. The diffs you can get out of it are calculated on demand. Even if on-disk storage can end up using some diffs to save on space, the actual conceptual model of every operation is based on those snapshots, and that is also how every new commit is stored before repacking the repository.
This appealed greatly to us, and always meant that it is effortless to undo any operation because it only creates new snapshots, while the previous ones stay there for a while in case you need to recover the previous state.
This is in contrast with Mercurial, where the data store is (was?) a sequence of diffs, and then the state of the working tree at any time is reconstructed on demand from those diffs.
I don't know what you mean by ergonomics, but I remember trying both Mercurial and Git back in the days after using Subversion before. I didn't like how Mercurial didn't easily let me rewrite history and do stuff like `git commit --ammend` or `git rebase`. Mercurial users kept telling me using an extension to manage patches on top of Mercurial (I think it was quilt).
I agree about the Windows support. hg serve was also nice. Plus TortoiseHg.
I'd made the exact same choice around the same time at the company where I was working. Last I heard, they're still using it. My rationale was that Mercurial was a lot safer and user-friendly compared to git. Needless to say, git has improved by leaps and bounds since then.
Echo your comments: Mercurial seemed more logical, and had one way of doing things. Have gone over to git, but still need to search for the command that I need.
Best part about open source -- Mercurial is still around, I use it for my home servers, and it's being maintained. I can use git, but Mercurial's workflow just makes more sense to me.
I don't think Git winning a popularity contest is a reason for choosing Mercurial to have been wrong, or unfortunate. Was there some negative consequence from the decision -- either directly from Mercurial itself, or just because over time everyone expected Git, perhaps?
(Hopefully this comes across as curious, which it is, and not antagonistic, which its not)
Not GP but there is a consequence. These days if someone has used version control they almost certainly know Git.
That means pretty much everyone who comes in the door needs Mercurial training, whether formal or informal. You’d get the same effect from still using CVS, SVN, or other things.
That may not be a big issue. If someone understands version control I’d hope they could adapt to another minder pretty fast.
I used Mercurial back in the day too. I agree, it was better. That being said, GitHub was better than other similar services which no doubt helped git win and now, git is ubiquitous.
I hate that social factors like popularity are a thing in technical decisions.
I have not used mercurial (though heard good things about it) but I saw a similar thing play out in Rust gamedev. There are 2 competing game engines, one better technically, the other much more popular. Now, if everyone made a purely technical decision, they'd pick the first one and eventually it would become the more popular one. Unfortunately, whenever I asked people why they chose the second one, they said because it was more popular. Tragedy of the commons.
If it's any consolation, maybe jj will take over. I haven't tried it yet (I use the staging area a lot in my workflow), but AFAIK they made the choice to be git-compatible which means it's not a choice between one or the other but lets people and teams migrate gradually.
FWIW you can still have a staging-area-like workflow with JJ - it's just that while git has "commits", "the staging area", "the working directory", and "stashes" as four separate concepts with four separate toolkits, in JJ all of those things are "commits" and a single toolkit works with all of them :)
We used Mercurial at reddit. We switched to it shortly after switching to Python as our main language, figuring it would be easier to use the one written in Python.
We used Mercurial until the day we went open source. We actually preferred it, but we knew at that point that "everyone" used Git, and we would never be seen as serious or get user contributions unless we switched. That was back in 2008. [0]
We actually self hosted a ticketing system[1] and our own git repo, but since the system we used didn't have pull requests, we had to use the old school method of sending us a patch via mailing list using the git-send-email command, the same way the linux kernel did it.
The best part of this is that we had a launch party for open sourcing in San Francisco. The date of the party was chosen a few months in advance, because it takes that long to plan something in physical meat space. This was basically the first time reddit ever had a hard deadline to get something done.
I was primarily responsible for setting up the ticketing system and code repo, and at the same time, we were switching our actual servers to pull from our public code repo for deployment, for true transparency (and I had to set all that up too).
I actually had to do the final setup to make everything public sitting at the bar at the venue with my laptop about five minutes before we opened the doors. At the time, I had about a week of experience with git! And here I was, operating what was expected to be a very popular open repo that anyone could clone from. Good times.
Mercurial was safer and better. I still use it and it's still safer.
The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though. I'm probably dumb but I can't work it out and hence the overall tool is that much less useful.
It needs a github-like website and Heptapod would be great if I could use it - I've set up a project, been unable to do anything and then had it all closed down. OTOH self-hosting is a lot more feasible nowadays with today's fibre connections.
> The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though.
yup, it came up as a response to git and people getting more and more re-wired into thinking of "branches as pointers", with its own bag of implicit state and behaviour. No wonder it felt clunky and unpolished used in this context. That said, it was a pretty effective way to globally distribute a namespace of string→commitID pairs, i.e. a list of commit bookmarks, and at least in that sense the feature wasn't a total misnomer/let-down :-)
I hated so much how Mercurial dealt with short-lived branches, that after seeing how Git did it, I've never looked back. I also remember how some people told me to use the quilt or something extension to manage patches, but it was too complicated for me.
It make a lot of sense if you think of repo history as properly immutable, and dispose of the notion that brach is a first class object in the git sense. Bookmakers just pin a checkin hash to a name, and you can have many heads in an hg branch.
Short-lived branches are likely referring to "bookmarks" in Mercurial. Or they could also just be un-named anonymous heads. These are different from what is exposed by the "hg branch" command.
Mercurial's "branch" was generally intended for long-lived things. Think the "stable branch" or a "version X" support branch for a project.
The branch name is baked into the commits that use it. You can hide them from the UI with "--close-branch", but they will still exist forever in the commit history. This is both a good thing and a bad thing, depending on your desires.
This is different from Git's "branch" which is basically just a pointer to a commit. It is not part of commit history, it is just a convenience for the developer. Later, Mercurial added "bookmarks" which are similar.
At my previous big tech employer we used to have a mercurial layer on top of our legacy version control system. I loved it, much simpler and more clear than the typical workflows I have to deal with in git. I get it that with git you have more power, but do really most teams need that?
Mercurial wasn't as simple as Subversion. But with hg I still felt like understanding 80% of what the tool had to offer and actually being able to mold the timeline the way I wanted.
Git has so many gotchas, bells and whistles that whenever I'm doing something out of the ordinary I'm wondering if there isn't an easier / canonical / smarter way I should be doing it.
There was a quote somewhere about Mercurial having a mental model small enough you can fit in your head - and that was the big win for me.
It was also fast and had very clean, easy to contribute to code. I remember submitting a patch and getting a bit of Python education from Matt, which was very useful.
Git is fine but it's inconsistent enough in the interface department, even after all this time, that I still get regularly frustrated. On the other hand, you can't just break a workflow that already exists and I very much appreciate it scales to work far beyond mine.
I do like that the git people are doing the difficult work of improving the UI over time - it's hard to change the engines while the plane is flying!
git's mental model is very, very small, if you care to learn it. Then all the commands and their "inconsistencies" start to make sense - they operate on the model almost without any magic, and not on whatever is user's intent (it can vary a lot)
What? Subversion is by far the most complex versioning software I've ever used.
> Git has so many gotchas, bells and whistles
The Git UI leaves a little to be desired. But inside, Git is basically just blobs, trees, commits, and refs. It'd be hard (or impossible?) to find a conceptually simpler versioning system.
Subversion pre-1.5 was a nightmare. Branch merges were by convention in commit messages. To merge 20 commits from your branch, you would do `svn merge -r 125:140 /branches/my-feature` and then note in the commit message which range you merged.
1.5 made that tracking automatic but just shoved it into a metadata field that just percolated through every directory in a project.
And if someone tried to rename a core path? In the distance, sirens.
I found that doing anything even slightly unusual in Git was pretty incomprehensible until I learned its internals, and pretty easy once I did. Fortunately as you say the internals are conceptually pretty simple to learn.
Unless git has some hidden way to do changeset evolution (maybe with jujutsu on top?) then no - I'm pretty sure git is strictly less powerful than hg these days.
Anyone know what Matt Mackall is up to these days? He started Mercurial and got people involved early on with a lot of enthusiasm, you could tell he cared about what he created and the people who joined him ("hg crew"). I learned a lot from him on how to think like an engineer and saw him manage different personalities in the project in a kind and sincere way (I think this was around ~2010).
FYI: Matt Mackall is now Olivia Mackall [1], so that can make searching for things harder. Looks like they work at Valve, now? Agreed that they were a really stabilizing and healthy personality in the project, and made a lot of good early decisions, which Mercurial has continually benefited from. Eg: the commitment to backwards-compatibility [2].
Olivia uses she/her, and I believe she is now retired :)
I owe her and the Mercurial community a great debt. The community taught me how to think like an engineer building infrastructure and the importance of backwards compatibility, something I've tried to carry forward in tools like cargo-nextest.
+1 I learned so much about software engineering (Software design, network protocol incl how to handle backward compat in sane ways, ...) thanks to the mercurial community.
Jujutsu took the best parts about mercurial and enabled these to be used with git and git forges. Once I had gotten used to jujutsu I didn’t really miss mercurial.
I haven't used hg in years now, bitbucket discontinuing support is what killed it for me and I had no interest in self hosting.
My git usage is very basic, my gitconfig has been pretty much untouched for years but on those occasions where I get stuck or hit something I end up searching and usually get through a bunch of posts/comments/sites and wish I was using hg.
I loved Mercurial - still do I guess as I just installed it on the Linux Mint VM I keep around for messing with Linux. The thing I really liked about it was TortoiseHg, which provides integration between Mercurial and Windows Explorer. There is a similar TortoiseGit but, at least back when I was doing serious development, it had quite a few problems.
We support Mercurial project financially and we use it everyday. While I use Git for hobby projects, it does not cut it in terms of ease of use. Some newer SCM systems like jj look promising, but absence of tools like TortoiseHg undermines their possible adoption.
My first full time job after university was using hg, and particularly https://tortoisehg.bitbucket.io/ made it really pleasant.
Prior and post that I'd always used git but I'll always have a bit of a soft spot for mercurial, especially as our forge usage at the time predated strict guardrails and controls - we did code review, but it was your responsibility to tag the appropriate people and wait for them to respond, if you felt it was necessary to merge prior to that you could - but better be ready to defend that decision.
Glad it is still around. hg was the better experience as it had fewer command surface. But slower, and sometimes you need the extra detail commands to analyze the history.
I just installed it on a Raspberry Pi (with an otherwise too-small-for-any-other purpose SSD) for use at home. I wanted something with low power consumption, and I didn't want to have a single point of failure by running it in a container alongside everything else.
The only hiccup was forgetting that when pushing via the SSH connection, it will have paths relative to the home directory of my hg user.
IIRC Facebook switched to HG from SVN in the 2010s, one (main?) motivator being that the single repo was getting too big and svn’s only way was to start splitting it up. Which was against the philosophy of openness of the single repo. No idea what’s Meta doing now.
Last I checked (2 years ago) Meta was using Sapling, a very heavily customised open source Mercurial frontend with proprietary backend.
FWIW the Sapling frontend can also be connected to a Git backend, and I've been using that for all my open source projects to get the best of Mercurial's user experience niceness while collaborating via GitHub <3
Git likely won because of GitHub; I abandoned Mercurial quite early when it was clear that it had lost. It was good, but I cannot imagine using it today.
I liked too. It was `hg serve` [1]. Instant web interface and an easy way to share the repository with other people (assuming your computer was accessible from the LAN or Internet).
Honestly hg shot themselves in the foot by not releasing any stable API and making developers use their CLI interface. Between that and the performance and dynamic typing issues of Python, it was almost sure to lose the race to Git.
Git's filesystem layout has always been stable and Git encouraged developers to target it. Mercurial strongly cautioned developers away from its filesystem or source code APIs and told them to subprocess out to the CLI. To be clear, I dislike Git, but it was _designed_ with developers in mind (which isn't to say that it has a nice API, only that the Git people intended for Git to be extended). I prefer Mercurial's concepts and interface, but Mercurial was somewhere between indifferent and hostile toward developers.
Just a bit off topic. But is anyone still using git or whatever versioning in the traditional way? I hardly see myself using the git command these days. Everything I handled by Claude. From pulling to pushing to solve merge conflicts and more. In a way it doesn't matter anymore whether it's git or something else.
I say wrong because clearly Git won the war and I haven't used Mercurial since then. However, I still think I made the right choice from a technical perspective; I thought Mercurial was way more user-friendly while providing all the features and performance needed. But I guess I couldn't read the future in terms of which one would win out!
I still use mercurial for all my personal project where I don't need to care what anyone else thinks. It is pleasant to use good tools, just like I like to buy top quality rachets or such.
Otherwise, in Fossil, any text is just another artifact. Wiki pages can be stored as files in the repo ("embedded") and versioned in the same manner as code files (that is, exposed through the same interface), or tracked behind the scenes (in a separate database, IIUC, with a different interface). Tickets and forum entries are also tracked and versioned similarly to non-embedded docs.
Aside from everything being versioned, the visibility of the objects is quite good. The user interface, both command and web, is light-years better than anything Git related.
I highly recommend you check it out. Even if you find it doesn't meet your needs, many of the design decisions are instructive. I find it quite inspiring.
This is its moment though. It is so well suited for LLM coding tools. You can jam all the markdown context, skills etc into the wiki. The CLI has wiki and ticket tools so those are just available for it to use. Fossil does not mind if you use the repo DB for your own stuff, so you can log all your sessions in there, fts5 is plenty for as needed on demand retrieval.
Big changes to professional development over the last year and hard to predict how it will all shake out, but I think the tooling will converge on something that fossil already has all the structure for. I was a late adopter on LLM-assisted coding but already feel ahead of a lot of my peers because of how easy and effective this approach is.
I haven’t touched mercurial in like 15 years, and from what I remember its UX was superior to what Git provides today. It had an extension system which I don’t remember the full capabilities of so I don’t know if Git has even now matched up to that.
Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it".
In addition, Git's UX is hot garbage. I would constantly be doing rsync on git repos before any operation that is slightly weird knowing that I may put the repo in some state that I cannot easily unwind. I never did that for Subversion. I never did that for Mercurial. I don't do that for Jujutsu. Those are all sane UX.
Side note: Thankfully AI is REALLY good at telling you how to un-wedge your git repo. That should tell you everything you need to know about Git UX and why you should avoid Git.
Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the exception?
My own setup differs in slight ways from what those scripts expect, and even where they match I like to do my own customizations. I don't want to commit those changes, and staging makes it easy to not do that MOST of the time. The rest of the time, it's a `git stash` dance, which I sometimes screw up and lose the customizations.
I've tried to manage the configurations a different way, such as by having a private branch with my own settings checked in, but that doesn't usually work out. I'm aware that the REAL problem is that my coworkers have checked in those settings to begin with, but I would counter-argue that the REAL REAL problem is that those tools don't have a good way to combine "settings that I override or that only I care about" and "settings that have project-wide defaults but are safe for me to override." (Visual Studio gets it close to right with its .xyzproj and .xyzproj.user files, but VS Code's single .vscode/ folder breaks down in shared repos.)
(If you're not interested, feel free to skip the rest of this).
I have each in process workstream in a commit that is merged at the top level, then I have a new wip commit off of that where stuff I'm typing right now sits.
It's easy to split/squash/absorb parts of that commit into the right destination, but also to introduce parents of the megamerge that will never get merged.
(This is a better/longer writeup of this concept)
https://isaaccorbrey.com/notes/jujutsu-megamerges-for-fun-an...
https://git-scm.com/docs/git-update-index#Documentation/git-...
So yes, your usecase does not make sense to me.
There was another comment that said similar thing...
https://news.ycombinator.com/item?id=48175289
>So you're just constantly committing untested versions of you work?
But it is "dead" for some reason...
2. Why should comments or printf statements affect the build? When it compiles with them, why shouldn't it compile without them?
3. the commits might be temporary and get squashed anyway
2. Because people make mistakes. You might think you are only excluding a comment, but might be excluding something that is required by mistake.
1. git stash
2. build + test
3. commit
4. git stash pop
> Some projects might not have a CI at all.
Well, then you have bigger problems. Without CI, how would you even know if your projects compiles on other platforms?
This way I remove the overhead of doing a staging before every damn commit and still retain the ability to pull in debugging changes whenever I want them.
>Without CI, how would you even know if your projects compiles on other platforms?
Not everything need to be cross platform! And not everything need CI..
As I said, I like to work on several things in parallel and I don't want to switch branches back and forth. That's just my workflow for my own projects and apparently I'm not alone.
In fact, often partial commits are necessary for builds.
As an example (and to be fair, this was a transitional project), I once worked on a project where the local dev directly acquired packages from different parts of the application, but the actual CI was broken up into different pipelines which required some parts to be built first, its outputs packaged and added to the registry, and downstream parts to be built after.
Committing everything at once would literally break the CI.
But there are also other extensions that can achieve similar behavior.
Oh, and I use git add ---patch almost exclusively. It's rare that I just do a "git add". I'm building up my stage, I'm checking it, I'm fixing it (if I accidentally stage something which doesn't belong), then I commit.
Having done it like this for a great many years I'm benefitting from it all the time. I can look at all my hobby projects (looking at the commits), and I'm back in where I left off, and I see excactly what I was doing back then (which, obviously, I wouldn't be able to rembember otherwise).
CVS though.. that was harder to do right. So a lot of stuff became just snapshots. You had to plan much more carefully. And then there was SCCS before that.. and before that again, well. Manual "keep two versions" svc.
It’s a pointless addition. Making commits easier to modify and undo would eliminate any need for git add.
But git can’t really do that since it’s so fundamentally based on the idea that commits are immutable. Any modifications r does allow are workarounds, and dangerous ones at that.
Supposedly, Meta has the data to support the claim that you (and I) are the outliers here. Staging is confusing to users, especially new ones, which is why jujitsu explicitly doesn't have staging.
Try doing the same in any other source control system…
On the off chance that you haven't already had this suggested to you on HN, I would suggest taking a look at JJ.
I use it in all my Git-underneath repos with `jj git init --colocate` (You can run that in a git repo and it will hybridize, or in a new folder and it will init and hybridize).
It doesn't have the staging concept, treating the working copy as just another commit (@), and to boot it snapshots the state of the tree into @ when you run any jj command, so you can use `jj op log` to see every intermediate state of your working copy at any time.
Commit is just `jj commit` with no staging mechanics, or `jj split` to 'split the working copy commits' (commit some, keep the rest in @).
not to mention the early "just clone it into a new dir" answer before lightweight branching ...
A good way of thinking about it is that every commit is itself version-controlled, allowing unlimited edits. This even allows two people in an evolve-enabled repo to make changes to history at the same time, and Mercurial will resolve any conflicts. It makes it trivial to commit (and even share) a "WIP" commit which you can later amend/split/whatever. It's different from git where you basically can't edit history after pushing (in Mercurial this only becomes true if you push to a non-evolvution or "publishing" repo, where everything then gets squashed for public consumption).
I stopped using it the first time I committed something I didn’t want to, over a decade ago, haven’t used it again since so I forget the exact invocation, but I think it was just “-a” or something.
Before it bit me though yeah, that did seem like a default I’d have preferred. Not any more.
`git add -p` FTW
Git is extremely predictable, but only after you thoroughly understand it. Until then, it seems to surprise you often and every time it happens you think you've lost data. Many times I've had collaborators who said "git ate my files" and I can usually get their files back in a few minutes. This makes them hate git because they cannot use it without having me on call, and they cannot be bothered to learn git thoroughly themselves because it's too damn hard.
Honestly this is one area I really like AI - so I can focus on the things I really need to focus on and not spend a bunch of time becoming an expert in things I don't want to be an expert in.
I guess it'd take one day of your life to read it, but I think it pays back a lot.
Using rsync on git is like hammering a nail with a hammer, but then use a 10 pound stone to hammer the hammer.
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.
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.
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.
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.
hg histedit gives you a TUI which shows an interactive list and allows quick manipulation with the arrow keys and single characters for actions.
The two are as "equivalent" as i3 and KDE.
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.
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.
Considering the number of kids that I've managed to understand git, I think this might be a teaching issue.
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.
As for `hg next`, the various responses here should show how clear, obvious, and intuitive the git UI is: https://stackoverflow.com/questions/6759791/how-do-i-move-fo...
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?
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.
Not that I think mercurial didn't have "simpler" UI back then, but the arguments thrown around in this thread are pretty bollocks.
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.
With any other system, your only option is usually checking out a fresh copy from a server or backup.
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!
If you’re claiming to have never needed any kind of undo functionality, you probably don’t even need a version control system :)
https://stackoverflow.com/questions/7376915/recover-lost-fil...
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.
Isn't the entire git rebase logic written in Bash scripts? Or was originally?
This fallacy again. Tell me, when did Mercurial decide "ok the prototype is done, we'll rewrite it in a proper language"?
They didn't, of course. Because nobody ever does. Your "prototype" gradually becomes a 100k line product that you can't afford to rewrite.
(I guess you can YOLO it with AI these days but that wasn't an option for Mercurial.)
> Starting with C was great for performance of Git, but damn if it's not a terrible UX these days
Git's terrible UX doesn't have anything to do with C. C doesn't make you always pick a different flag for "delete".
- 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.
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.
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.
> 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.
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.
Conceptually, branches in git and mercurial are worlds apart.
...than git? than hg?
So already the naming in git is very confusing, and conceptually it clearly is very different from Mercurial because of this reason.
Another contender is Jujutsu (jj) which allows you to use jj as frontend and use Git as the backend (with the potential to support any backend, e.g. Google's proprietary Piper), with the best ergonomic and the widest availability of hosting solutions.
I use git mostly on single-dev projects, with branched development patterns.
Would someone like me with a simple git use-case find JJ enjoyable?
Nah. At the time BitBucket was the better way to do open source projects, and they were Mercurial-first. But eventually they had to add Git support because there was so much demand.
But to offer a point I haven't heard from anyone before: at least I feel that I am done with it, I learned this tool sufficiently and I can move on with my life. From time to time I add something to my git toolbelt. I feel if Mercurial or anything else have won, I would maybe have to learn another tool in 5 years, whatever else got popular, and another in next 5 years. But now I have everything I need in git, and always have needed. I hold some hope in it that perhaps the learning curve was worth it.
I’m glad there is one clear winner and we’re not in the common position of having 2-3 relevant/semi-relevant choices that you’re frequently asked to switch between depending on which project you’re looking at at the moment.
Git is modern version control, whatever you think of it, and there’s a simplicity to that.
If git doesn't let you do them "right", your concept if "right" is wrong.
After Linus Torvalds gave this talk at Google in 2007, it was clear he would win. (Is there a better quality video somewhere?)
https://www.youtube.com/watch?v=idLyobOhtO4
But I agree: Mercurial was definitely friendlier for people who didn't have time time to go through the technicalities of git. To use git smoothly you pretty much need to learn how it works internally.
I might say that I stopped thinking too hard about this many years ago: now I use hg-git whenever I must interact with git, but do regret that the more sophisticated/qol features of hg (branches, evolve, phases, topics, ...) don't exist in git, and that's the real bummer: the more limiting alternative won, then stagnated, and we are all worse off as a result.
Mercurial had bookmarks that were roughly the same as git branches.
The linear version numbers were quite useful to reason about and use in places that call for a "number" version number, and were useful relative to your "master" clone. That was not the primary way though, it had hashes like git too, that were the same from clone to clone.
And then, when you pull someone else’s in-progress work to inspect it, you end up with their branches showing up with their names and you ended up with revisions 13564-13592 belonging to someone else and showing up in your history graph even when you continue on your own work at revisions 13563 and 13593. I ended up using temporary clones and strip a lot.
git branches, in contrast, are delightfully unobtrusive.
Finally, in one team, I more or less forced a senior engineer use merge (or rather, I was in control of the project and did not force other developers to use rebase). After a year, he admitted that he no longer really saw a benefit in rebase and switched to just using merges in his own projects. He also noticed fewer merge conflicts this way.
You mean - when looking at the history?
Incidentally, once you get used to jujutsu, you realize that the question is meaningless. A merge is simply the child of two nodes. It's a symmetric operation between the two branches. The thing that makes it "complicated" in git and traditional VCS's is the insistence in assigning a name to the resulting merge (so if you're merging into main, you want to call the new node "main"). Since jujutsu doesn't automatically carry the name forward, you see the "reality" of merge being a symmetric operation (i.e. you don't merge a branch "into" another branch - you are simply merging two branches).
For a complicated long running feature branch I can see it. Instead of repeatedly merging the root in during development it can be cleaner. Tools aren’t always good at figuring out in a PR what was written and what was caused by those merges from root. And history looks better at the end.
For a short branch that can merge cleanly or perhaps very close to it, I’d kind of rather have the ‘true’ history. I don’t think it’s worth it.
I’ve never understood the “everything must be rebased before every merge” desire.
"For a complicated long running feature branch" always simpler to repeatedly merge main into dev, easier conflicts solving etc
For simpler cases squash+rebase as default merge strategy trumps leaves a nice clean history.
That said, if/when stacked PRs become a first-class citizen in GitHub, more projects will see the benefit of this approach (though they'll probably mostly get there through squash-merges).
What does “far better tooling” mean exactly, could you give an example of what amazing tools I’m missing out on (never have used anything else but git, when I came to the industry it was already the standard)
TortoiseHG is a very good client that covers all common Mercurial operations and then some. It's on par with a couple of commercial git clients that I've used. On the server side, there's e.g. heptapod as a GitLab fork that has a deep Mercurial implementation.
Although, I suppose part of this is just that manipulate index with something like lazygit.
It means that git invented a bunch of new jargon and ideas that confuses people exposed to it for the first time, where hg's usage metaphor hews closer to the received wisdom of people coming from stuff like subversion and perforce.
It's true that git's ad hoc command line UI isn't exactly it's greatest strength. But given the complexity of the design space here that's a pretty weak argument IMHO. The two weeks it takes to get the basic git workflow into your muscle memory pale in comparison to the years it'll take you to be good at bisection and tree maintainership.
It's also sort of a wrong argument in the modern world. People new to git have extensive assistive technologies available. There is, after all, no HgHub out there.
I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches, of even we could perhaps install a module such as shelve.
That was the image that Mercurial left with me with regards to git: missing critical features and not bothering to bridge the gap.
I started with Mercurial, eventually got forced into git, and now use jujutsu.
Totally agree with the Mercurial developers: Just use a branch/bookmark. When I encountered it in git, it seemed neat, but became yet another concept/thing to clean up that you don't need to.
And lo and behold, after switching to jujutsu, everyone shows how you can do a stash using an (anonymous) branch.
Even though I used stash a lot in my git days, I don't miss it at all while using jujutsu. The benefit of jj is the ease with which one makes branches (without needing to name them). That's why you may not have liked the advice in mercurial - it wasn't the solution that was problematic, but that mercurial didn't make it as easy as it should have been.
(Same goes for index - no one misses it once they switch to jujutsu).
This topic is not about stashing though. It's about UX and providing first-class support for a basic use flow. If git stash was an alias for creating a branch and committing local changes to it, the point still remains: the problem with Mercurial was how it went way out of their way to argue against supporting features that users actually wanted, and supporting it as a first class feature.
And to me that's why ultimately Mercurial was bound to be forgotten while the tool that met uses' needs attained the status of de-facto standard.
The same can be said about other major features such as support for large files.
To top things off, the way that git maintainers have been actively adapting to feedback from jujutsu's users is yet again proof of why git still remains the de facto standard.
The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off.
I think some of the extensions were very basic stuff like graph logging and colorized output -- and mq like you said. So it was kind of unfortunate that people got a bad impression of hg from that and bounced off.
20 years ago, Mercurial was not the wrong choice.
- Its internal design was very similar to Git's.
- Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.)
- Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model.
- (It had a third major advantage over Git that I unfortunately cannot recall at the moment.)
So you weren't wrong back then...
...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.
That's a matter of taste. I used both for serious work, at the time, and found Git much more usable. My experience with Mercurial was "welcome to Mercurial, how can we help you merge and push your work in progress even though that's not what you want?" My experience with Git was one where I felt in control at all times, had a clear workflow for when I did and didn't want to publish my changes (and for when I wanted to edit them first), and allowed me to quickly make and switch branches within a single working copy.
People always say you have to know git internals in order to use it, but that's just not true. Git has the right data model and has always been about empowering users to edit their data. Which makes the data model be "in your face" compared to the alternatives (and I think that's what people latch on to when they talk about "internals"), but it ultimately makes for a better tool.
This appealed greatly to us, and always meant that it is effortless to undo any operation because it only creates new snapshots, while the previous ones stay there for a while in case you need to recover the previous state.
This is in contrast with Mercurial, where the data store is (was?) a sequence of diffs, and then the state of the working tree at any time is reconstructed on demand from those diffs.
I agree about the Windows support. hg serve was also nice. Plus TortoiseHg.
I don't remember evolve [2] at all.
[1]: https://repo.mercurial-scm.org/hg/help/histedit
[2]: https://repo.mercurial-scm.org/hello/help/evolve
One of the first things I did was switch us to git.
Mercurial was way easier to use and fit our use case but all the tooling was built for git.
Echo your comments: Mercurial seemed more logical, and had one way of doing things. Have gone over to git, but still need to search for the command that I need.
(Hopefully this comes across as curious, which it is, and not antagonistic, which its not)
That means pretty much everyone who comes in the door needs Mercurial training, whether formal or informal. You’d get the same effect from still using CVS, SVN, or other things.
That may not be a big issue. If someone understands version control I’d hope they could adapt to another minder pretty fast.
It’s still an issue. There is technically a cost.
I have not used mercurial (though heard good things about it) but I saw a similar thing play out in Rust gamedev. There are 2 competing game engines, one better technically, the other much more popular. Now, if everyone made a purely technical decision, they'd pick the first one and eventually it would become the more popular one. Unfortunately, whenever I asked people why they chose the second one, they said because it was more popular. Tragedy of the commons.
If it's any consolation, maybe jj will take over. I haven't tried it yet (I use the staging area a lot in my workflow), but AFAIK they made the choice to be git-compatible which means it's not a choice between one or the other but lets people and teams migrate gradually.
That's a different concept. You are describing network effects.
We used Mercurial until the day we went open source. We actually preferred it, but we knew at that point that "everyone" used Git, and we would never be seen as serious or get user contributions unless we switched. That was back in 2008. [0]
We actually self hosted a ticketing system[1] and our own git repo, but since the system we used didn't have pull requests, we had to use the old school method of sending us a patch via mailing list using the git-send-email command, the same way the linux kernel did it.
The best part of this is that we had a launch party for open sourcing in San Francisco. The date of the party was chosen a few months in advance, because it takes that long to plan something in physical meat space. This was basically the first time reddit ever had a hard deadline to get something done.
I was primarily responsible for setting up the ticketing system and code repo, and at the same time, we were switching our actual servers to pull from our public code repo for deployment, for true transparency (and I had to set all that up too).
I actually had to do the final setup to make everything public sitting at the bar at the venue with my laptop about five minutes before we opened the doors. At the time, I had about a week of experience with git! And here I was, operating what was expected to be a very popular open repo that anyone could clone from. Good times.
[0] https://web.archive.org/web/20080619043654/http://blog.reddi...
[1] https://web.archive.org/web/20080622134154/http://code.reddi...
The bookmarks feature which is supposed to be the solution for short-lived branches is hard to understand though. I'm probably dumb but I can't work it out and hence the overall tool is that much less useful.
It needs a github-like website and Heptapod would be great if I could use it - I've set up a project, been unable to do anything and then had it all closed down. OTOH self-hosting is a lot more feasible nowadays with today's fibre connections.
yup, it came up as a response to git and people getting more and more re-wired into thinking of "branches as pointers", with its own bag of implicit state and behaviour. No wonder it felt clunky and unpolished used in this context. That said, it was a pretty effective way to globally distribute a namespace of string→commitID pairs, i.e. a list of commit bookmarks, and at least in that sense the feature wasn't a total misnomer/let-down :-)
Mercurial's "branch" was generally intended for long-lived things. Think the "stable branch" or a "version X" support branch for a project.
The branch name is baked into the commits that use it. You can hide them from the UI with "--close-branch", but they will still exist forever in the commit history. This is both a good thing and a bad thing, depending on your desires.
This is different from Git's "branch" which is basically just a pointer to a commit. It is not part of commit history, it is just a convenience for the developer. Later, Mercurial added "bookmarks" which are similar.
Git has so many gotchas, bells and whistles that whenever I'm doing something out of the ordinary I'm wondering if there isn't an easier / canonical / smarter way I should be doing it.
It was also fast and had very clean, easy to contribute to code. I remember submitting a patch and getting a bit of Python education from Matt, which was very useful.
Git is fine but it's inconsistent enough in the interface department, even after all this time, that I still get regularly frustrated. On the other hand, you can't just break a workflow that already exists and I very much appreciate it scales to work far beyond mine.
I do like that the git people are doing the difficult work of improving the UI over time - it's hard to change the engines while the plane is flying!
What? Subversion is by far the most complex versioning software I've ever used.
> Git has so many gotchas, bells and whistles
The Git UI leaves a little to be desired. But inside, Git is basically just blobs, trees, commits, and refs. It'd be hard (or impossible?) to find a conceptually simpler versioning system.
1.5 made that tracking automatic but just shoved it into a metadata field that just percolated through every directory in a project.
And if someone tried to rename a core path? In the distance, sirens.
Show a diff: svn diff / git diff
Show log with diffs: svn log --diff / git log --patch
Git calling the same or similar things different (or just terrible - tree-ish? ref?) names is one of the worst things about Git.
[1] https://repo.mercurial-scm.org/hg-stable/rev/d4ba4d51f85f
[2] https://wiki.mercurial-scm.org/CompatibilityRules
I owe her and the Mercurial community a great debt. The community taught me how to think like an engineer building infrastructure and the importance of backwards compatibility, something I've tried to carry forward in tools like cargo-nextest.
If there were a reliable way to use Mercurial on a Git repository, it could live. But why bother when one can use Jujutsu?
My git usage is very basic, my gitconfig has been pretty much untouched for years but on those occasions where I get stuck or hit something I end up searching and usually get through a bunch of posts/comments/sites and wish I was using hg.
Prior and post that I'd always used git but I'll always have a bit of a soft spot for mercurial, especially as our forge usage at the time predated strict guardrails and controls - we did code review, but it was your responsibility to tag the appropriate people and wait for them to respond, if you felt it was necessary to merge prior to that you could - but better be ready to defend that decision.
Not sure why it has to disappear in the first place.
What's going on with hginit.com now ?
The only hiccup was forgetting that when pushing via the SSH connection, it will have paths relative to the home directory of my hg user.
FWIW the Sapling frontend can also be connected to a Git backend, and I've been using that for all my open source projects to get the best of Mercurial's user experience niceness while collaborating via GitHub <3
I guess I just wanted to say I hate perforce lol
[1]: https://mercurial-scm.org/help/commands/serve
Hg is a superior tool compared to git. It logically just clicks, for everyone. Changesets, branching, merging, tagging, it all just works.
Git is this arcane blob of whatever-you-call-it where rewriting/erasing history is not only allowed, its encouraged. That is insane to me.
Git is a fine tool, it is in every possible way inferior to hg.