Is there a reason why they used Mercurial as opposed to git? Did it provide some benefit?
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.
Ahhhh, thanks for brining back those memories.
You're not thinking about BitBucket are you? I thought Github was always git only?
What I mean was that it wasn't like Bitbucket where you chose whether you wanted git or hg for starting your project.
I think Google Code provide both from the early day (along with Subversion), and maybe also SourceForge.
That was over a decade ago, however; I'm actually pretty surprised it took Mozilla so long to switch.
I'm a happy git user but I'm really curious about losing good ideas from other tools due to mindshare.
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.
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".
If git was an equivalent modern appliance, it would be against the Geneva convention.
I give Git this, it's a bit faster.
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).
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?
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.
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.
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.
Edit: See also this point by point breakdown: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
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.
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.
Edit: I work for Mozilla, although I didn't in 2006 when I think the decision was made.
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.
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.
That's how Sourceforge rose to become so dominant it appeared unstoppable, and how Docker became immensely popular so quickly.
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.
So Linux was always going to be git; and I think things flowed from there.
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.
But Git definitely won the war, and Mercurial has been disappearing little by little.
Might not have much to do with git vs Mercurial technical merits.
But not for the reasons that correlate, such as education, tooling.
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.
Worse is better wins again.
Read about Jujutsu awhile back.
I am quite surprised that no open source variant has been created yet (that I'm aware of).
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.
Then git-svn was born, and you could branch instantly. This was such an obvious improvement that all future repos moved to git.
Merging in SVN on the other hand…
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.
So, no my friend, a lot better wins time.
hg clone ssh://example.com/repo
cd repo
hg update -r $SOME_COMMIT_HASH_OR_ID
```
Unless you mean you want to delete history back to a certain point, in which case it's only slightly more complicated.
https://soberbuildengineer.com/blog/2007/04/version-control-...
https://soberbuildengineer.com/blog/2006/11/version-control-...
Unfortunately, GitHub got VC funding and caused network effects to kick in.
Git came along with GitHub as a parasite much like C came along as a parasite with Unix.
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).
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.
It's more complex comparing with git naked graph. Contains more domain entities. But it could be more convenient for starters and SVN users.