+1 for Chess. Such an amazing game, one could spend (some might say waste) their whole life dedicated to it, or just a couple minutes here and there. It's fun either way.
The two came out at roughly the same time and for the first few years it wasn't really obvious which was better.
Personally, I chose Mercurial to start with, because I liked the Windows tooling available and it felt a lot more like Subversion, which is what I used previously.
However, Git won the mindshare war in the end, so I moved over to that.
Happened the SAME thing to me. Mercurial felt more natural than git. Back then, Github allowed you to choose the VC and Mercurial and Git were available, I'd always choose Mercurial. I was also using Google Code that allowed for mercurial as well.
Oh that's right - I'd forgotten about that april fools joke that wasn't. It was just client compatibility right - the backend was still git from memory?
What I mean was that it wasn't like Bitbucket where you chose whether you wanted git or hg for starting your project.
The Xen Project chose Mercurial to replace Bitkeeper (the proprietary but free-as-in-beer-to-open-source-projects-for-a-while VCS that Linux used before it became no-longer-free-as-in-beer) as well. There were things that were nicer about it; but in the end it just made more sense to move over to git.
That was over a decade ago, however; I'm actually pretty surprised it took Mozilla so long to switch.
12 years ago I decided to try using Mercurial for tracking history of my plain text notes. I chose Mercurial for it's supposed better Windows support. Turned out that it couldn't work with unicode filenames. While git could.
After all the years, do you think mercurial still offers tangible benefits in terms of versionning workflow ? faster operations, more extensibility, things that are somehow only possible in hg and not git (or way too hard in git)
I'm a happy git user but I'm really curious about losing good ideas from other tools due to mindshare.
I now haven't used Mercurial in about 8-10 years or so. However, I recall enjoying the workflow a bit more, and I did like how commits were explicitly linked to branches as opposed to branches being effectively pointers to commits - it was nice to find out the original branch of any given commit.
However the killer feature of Git is the ecosystem. I was always having to do lots of custom work to get Mercurial to work with CI providers, whereas Git just worked and had first class support. It was clear after a while that our team would always be outsiders if we continued down that path, and there wasn't enough of a compelling reason to stay with Mercurial.
Disclaimer: I haven't touched hg in nearly a decade.
hg has (had?) a sane CLI that blows (blew?) git out of the water.
I like the power of git, but it either needs external tooling to prevent people from shooting the team in the foot, or relatively thorough study by everyone using it.
In practice, for git, most of the time you need some software to protect people from messing up repositories and history (gitlab, github, etc, which honestly you're gonna use anyway), while hg on its own protects you out of the box from most mistakes.
All FAANGs I'm familiar with use git, but there are some serious handrails and straps on what you can do. On smaller companies I had so many arguments about rebasing public branches that it's not even funny.
For a while I had in the back of my head to create a hg clone that was a wrapper around git, in a way that it'd allow hg-style workflows and protections, while having a faster and more well-known "backend".
Git is not opinionated and doesn't care about your workflow, which is why it won in the end. (The downside is that, yes, it's ultimately just a collection of tools, not a "framework" for doing software.)
Maybe, but normal developer interracts with sane parts.
Honestly, the biggest problem with git is sane environment for merge conflicts and that is out of scope of git CLI. In most cases, imposing rule for small PRs/feature branches will solve it.
git add, git commit, git log, git blame, git push, git rebase -i --onto. That is 95+% of what developers use (maybe an option here or there, like -m or --amend). Merges are done on CI after it passes.
There are a lot of arcane parts and switches. git-send-email is likely used a lot on kernel development, but very rarely in the rest of the world.
> I've got 10 years in it and it still bites me in the ass.
Can you give some examples? I had some problems in the beginnings, but it was because i tried to be "smart".
After I embraced KISS, everything works nicely. As long as I keep "public" branches protected, any splash zone is very small and at worst, just redo it(synergy with small PRs).
I haven't touched it in a while, but AFAIK multiple heads in a branch only happens when you commit twice against the same changeset in the branch. I don't see how this can happen accidentally. Either way you want to merge them back under a single head (a normal 'hg merge') or remove the spurious head ('hg strip'). Maybe it was more complicated at the beginning?
> Except then it’s not a history of what actually happened?
What do you mean? Hg and Fossil don’t capture what “actually happened” either, they don’t show you stuff you typed and deleted before committing. They don’t save the compile errors you had or what you tested and changed. They don’t save what you said to your coworkers about their code because they were afraid to set their changes in stone or make a mess. They don’t prevent anyone from putting things into the commit log in a different order than they “actually happened”, and they can’t: these are systems that record only what you tell them. What problem, exactly, does trying to capture ‘what actually happened’ help solve?
I don’t understand this obsession with what “actually happened”, as if there’s something critical about auditing keystrokes, as if the working code and the state of the tree are secondary. No DVCS can prevent someone from designing what their commit history looks like. In the mean time, the idea that you shouldn’t be able to edit or change anything locally before showing it to other people seems like a negative force against the basic safety net that a version control system needs to provide. (And no existing DVCS actually prevents rewriting history anyway, they just claim to have preferences and they offer commands to rewrite history that have other names and say honor system, you shouldn’t use them very often.)
> revising it to make it look “clean” doesn’t actually help with anything.
Hehehe you’ve never had to look at the history then, I assume? You’ve never had to bisect? You don’t care if people interleave different topics in their branches, or make lots of 1-line fixup commits all over the place? You don’t care about how long it takes to find out who changed something, or whether you have to sift through a mountain of garbage to find it?
Don’t the DVCSs that have the ‘history is sacred’ dogma also have tools to make presenting and viewing history less noisy than the so-called ‘what actually happened’ commit log? Doesn’t that prove that a clean view of history does help, and is something a lot of people want?
> What do you mean? Hg and Fossil don’t capture what “actually happened” either, they don’t show you stuff you typed and deleted before committing.
They show you what you actually committed and don't allow you to do stupid things that might corrupt your repository, which is what matters.
> I don’t understand this obsession with what “actually happened”, as if there’s something critical about auditing keystrokes, as if the working code and the state of the tree are secondary.
"Working code" and important milestones in the state of the tree are tracked by tags, bookmarks and other features depending on what source control system you use. The state of the tree at every single commit point is an irrelevant detail.
> No DVCS can prevent someone from designing what their commit history looks like.
Correct, and they shouldn't encourage you to waste your time trying to do so, and so shouldn't make it easy either.
> Hehehe you’ve never had to look at the history then, I assume? You’ve never had to bisect?
I've been doing it for over 20 years, first with subversion, then Mercurial. Never had any issues figuring out what was going on. Taking a few extra minutes here and there to scan through such changes is nothing compared to trying to fixing a repository corruption, which is something I recently had to deal with.
Everything you describe can be handled by 1) a better commit log history tool and more importantly, 2) better development practices that requires adding proper comments and tickets to code and commits that describe context and rationale for changes. Opening up history to revisions is a sledgehammer trying to solve a bunch of distinct problems that require better solutions.
> Doesn’t that prove that a clean view of history does help, and is something a lot of people want?
Of course it helps, sometimes. As I've described above, that doesn't mean you should introduce a sledgehammer for the occasional pain point that can be addressed by other, arguably better means.
> They show you what you actually committed and don't allow you to do stupid things that might corrupt your repository, which is what matters.
Who cares what you actually committed on a per-commit basis, especially when fixing things that were mistakes in the first commit, and would have been committed as part of the first commit with more planning and/or no innocuous accidents? Who needs to preserve the already arbitrary order of commit commands, and why? I’ve never heard a compelling and real-world reason to need this, nor any popular workflow that this idea establishes or improves.
And what repo corruption are you talking about? I don’t know about you, but one thing people espousing this ‘what actually happened’ philosophy and trying to trash-talk git tend to deliberately overlook is that git commit histories are immutable, and rebase only produces a new commit lineage, with an in-tact backup of the previous lineage surviving anything you do. It’s not possible for the history to be irrecoverably corrupted, unless you’re unfairly including bugs or hardware failures. Recovering from rebase mistakes is simply a matter of learning where the undo knobs are, and ultimately they are pretty easy to use, it’s no more work and no different outcome than learning how to groom the presentation history of Hg or other systems.
> especially when fixing things that were mistakes in the first commit, and would have been committed as part of the first commit with more planning and/or no innocuous accidents?
Follow-up fixes reveal important nuance and implicit assumptions that shouldn't be erased.
As for your other claims of "simply" and "easy", you need only peruse this thread that covers plenty of rebase stories losing entire commit histories and requiring redoes of weeks worth of work to see either it is neither easy or simple.
Replying to your later edit. I’m aware of Fossil’s language, which is pretty hyperbolic. It’s largely a straw-man argument, because Fossil devs have presumed to state the intentions of git devs and git users, and they jump to a bad-faith conclusion in order to state their opinion that Fossil is better than git. Keep in mind the Fossil pages are marketing, and they are comparing themselves to the competition (git) by trying to paint git in a negative light, with prejudice. They wish they had the market share that git does, and so you should trust that language just as much as you trust a Pepsi TV commercial. Dr. Hipp has stated on HN his belief that editing code history should be considered a criminal activity, without sufficient justification for such an extreme and unique point of view.
BTW I have a ton of respect for SQLite and Dr. Hipp’s work. I love the way he has talked about testing. Nonetheless, I’m very much not a fan of their trash-talking of git that intentionally ignores the context, guidance, and real-world usage of rebase. The irony of them saying that git rebase is “dishonest” is that they themselves are being intentionally dishonest about how they talk about git, and I find it very off-putting and hypocritical, to be as polite as possible.
> Follow-up fixes reveal important nuance and implicit assumptions that shouldn’t be erased
That’s definitely not always true. In my experience that’s a small minority of cases, and when it happens, I keep the important nuance commits and don’t squash them. Nobody is forcing you to squash, it’s an option for the (many) fix up commits that were pure accidental oversight and have no nuance that needs to be preserved.
I’ve seen lots of people claim they lost work, because they freaked out or gave up without slowing down to think carefully. The reason is because they didn’t learn how git actually works, and never learned the undo buttons. I’m well aware that git’s CLI is intimidating and unintuitive, but one thing it does not do is corrupt your repo for you. That’s effectively a blaming excuse for not having learned how it works.
When the decision was made to use Mercurial, Git for Windows wasn't a viable option. If you wanted to develop on Windows, the choices were Mercurial or SVN.
Edit: I work for Mozilla, although I didn't in 2006 when I think the decision was made.
IMHO it was Github which made git popular. GH filled a gap left when Sourceforge went down the shitter, and Github was there at the right time to host open source projects for free. The actual version control system used (svn vs git) wasn't all that important. The important feature was free hosting.
Yeah, hardly anyone cared what Linux used (a few years earlier before Bitkeeper it was mostly just patches).
But Rails was a very early Github user, and the big Rails usage upswing coincided with that and helped drive it. I was a Python and PHP dev at the time, and that other stuff mostly predated Github and was scattered across all kinds of places. Whereas Rails and Github both kicked off about the same time, and practically no Rails devs or libraries used anything else.
It was that fast growth and hype combined with the network effects of Github that drove git usage rather than what Linux used. The Linux contribution workflow was also pretty alien to Github focused webdevs.
This. Free hosting has mass market appeal. It is a so much bigger market the product itself isn't terribly important. Not until the later pivot to a paid product.
That's how Sourceforge rose to become so dominant it appeared unstoppable, and how Docker became immensely popular so quickly.
>IMHO it was Github which made git popular. [...] The important feature was free hosting.
Bitbucket also had free Mercurial hosting in 2009. I think it was 1 private repo in the free plan and it was later expanded to unlimited free repos with max 5 users around 2011.
For sure; Github was also (IMO) responsible for the rise and success of NodeJS and its dependency ecosystem, and consequently the web based front-end ecosystem we have today (angular, react, vite, etc).
The main reason Linus didn't go with Mercurial was that Mercurial just wasn't efficient enough to do operations on the Linux repo with what Linus considered a reasonable speed. (I think it was maybe written in Python at the time?) Linus knew what the kernel was doing, so he could write a core engine that was a lot faster, and that mattered to him.
So Linux was always going to be git; and I think things flowed from there.
Wasn’t git written by Linus and chosen for Linux development before Mercurial was announced? Is the main reason Linus didn’t choose Mercurial because Mercurial didn’t exist when the decision was made?
Having used Mercurial for years in OSS projects before switching, my view is that pull requests on Github was a major factor.
There wasn't a similar offering for Mercurial, in part I think because of the fundamentally different way Git and Mercurial treated (treats?) branches. In Mercurial branches were permanent, so a PR-like flow would leave a lot of stale branches around.
Mercurial also didn't support rewriting history as a core philosophical choice.
It was introduced via a plugin but that meant each dev had to enable it to use it. AFAIK it has been moved into the core, but I think too late.
At least as a primarily Mercurial user at the time, I feel Git didn't really outcompete Mercurial until Github and PRs came along. It just allowed for much smoother cooperation.
Since then both had lots of optimizations put into it to work outside their original intended domains. Facebook did a lot to make Mercurial performance on very large repositories tenable. Microsoft did the same for Git to allow their Windows developers to work with Git, which apparently was initially not able to do common operations at all at acceptable speed.
But those are big company problems and I suspect the caveats, tradeoffs and solutions matter a lot less for the 99 % of other VCS users.
Not just Torvalds and hosting Linux development: Git solves "big code" problems and large organizations pull the market - including tiny projects for which Git's trade-offs are not optimal, where Mercurial tended to make users happier.
For me it was a quite important factor TBH in 2007 when I wanted to try something new outside of SVN. And it was my big argue point to force my company to switch to Git.
Yeah. From a technical standpoint Git is a lot worse in a lot of ways. From an ease-of-use standpoint it's about as much worse as it's possible to be.
Still, with Linux behind it, Git won the DVCS wars. Mercurial became an also-ran and now almost nobody uses it.
Too bad.
We'll need something new and innovative to come out and rid us of constant blogs explaining how Git works because it's too hard to understand how to make it do the things you want it to do.
I've been using Git for about 7 years now (5 exclusively) and I know how to use it, but I still have to look things up occasionally because its UI is trash and non-obvious. I didn't have that problem with Mercurial. There, I knew the verb and the built-in help was sufficient to get me where I wanted to go.
Just try to clone Mercurial repo (Firefox) and roll back in history to specific commit. Let me tell you beforehand - it is (at least used to be) impossible. What you could do is to "clone it again" up to specified point. You have to do it somewhere else on a filesystem just to needlessly spoil disk space and you end up having the same sources at least twice. When I asked why I got handwaving arguments about code history being sacred, which is of course nonsense. If it was so... in Git I'd make another branch and rewind to commit I care about without wasting another 25gigs of disk. How can be this achieved in mercurial these days (without waste)? Back in days I wanted to do some work specifically on Firefox, and those steps were the only I could come up with after a lot of searching and asking questions, and because of Mercurial I gave up, to me it felt like it was a high entry barrier on purpose.
> Yeah. From a technical standpoint Git is a lot worse in a lot of ways. From an ease-of-use standpoint it's about as much worse as it's possible to be.
Ten years ago, when I had started to use git after having used both Subversion and Mercurial, I noticed one thing.
Git was FAST.
On repositories of the same size, git was blowing Mercurial out of the water and running circles around it, that's how fast it was.
It was FAST and it fucking got out of my way and let me work.
I don't know the inner workings of either and academic advantages of Mercurial, but I know for a fact it had been a dog and its move to Python 3 had been disastrous. So whichever technical or UX advantages Mercurial might have, I simply don't care anymore.
> We'll need something new and innovative to come out and rid us of constant blogs explaining how Git works because it's too hard to understand how to make it do the things you want it to do.
Git did not run on Windows when Mozilla moved. Git on Windows required running Cygwin was prone to breaking on Cygwin and was slow. This was a pretty big dealbreaker for Mozilla. The imports of Mozilla's ~10 years of CVS dev via the version control's import tool was fragile and none of them imported cleanly without patches.
I'm a huge critic of git, but I think it won out on merits. Git was used by the Linux kernel, and therefore from the beginning scaled better to much larger projects than other DVCS systems.
Got scales very well with source code but does terrible with binary resources like graphics. The only time I’ve seen got really fail (but still work at slowly as other systems) is when some stubborn tech lead decides to put 3rd party source deps as tarballs in git.
> Except it doesn't scale to codebases the size of Facebook and Google.
Actually, it scales well with large codebases, but the monorepo mental model pushed by FB/Google doesn't match the git workflow model. Git repo design is for a concrete entity: a single tool, binary, service, kernel, whatever. When you start bashing in multiple unrelated projects where you try to have various per-project versioning schemas, it becomes a mess.
I don't really see a benefit of having all code of an org in a single repo. Single product, sure. But whole company? Why. Not to mention, these are serious outliers.
From security standpoint, it doesn't seem great, from practical side, it's not great (bandwidth cost ect).
There was similar push by Facebook to improve Mercurial perf and they showed some impressive advantage over Git. It seems it was abandoned eventually for Git.
In the early days, the git UX was quite rough around the edges and Mercurial was a lot more idiot proof than git was. Git has evolved significantly since then.
I am also interested in finding this out. So far, I've done a lot of teaching/training with Java but I am playing with Common Lisp and would love to see how others use it in education
I always find this article[1] interesting that talks about why MIT stopped using Lisp
Just tried this with my 5 and 7 year old and they loved it. We used wooden block toys
Both felt a little confused but after a round or two they were coming up with their own crazy secrets like "has a green piece pointing at the door". Going to look for Pyramid Arcade in the UK.
I've been learning and playing with Common Lisp. I've been involved in Java for more than a decade and wanted to try something new. I wanted to try something outside of OOP and more functional. I went from Scala -> Clojure -> Common Lisp. I've also switched to Emacs for almost all of my common tasks. That hurt as a long time Vim user :) but I'm enjoying it so far
Again, I started with solarized but moved onto other themes. I think it was one of the first themes that was implemented almost everywhere. It was nice to have my browser, IDE, window manager etc all themed up the same way.
I also appreciate the work he went into to set the color scheme up. I feel the same spirit with the Modus themes[1] for emacs
