[amluto]

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.

[rileymat2]

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.

[amluto]

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.

[ern]

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.

[BeetleB]

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.

[bluGill]

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.

[BeetleB]

> 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).

[bluGill]

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.

[MBCook]

Agreed.

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.

[dragochat]

exactly the opposite:

"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.

[atq2119]

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).

[pitkali]

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.

[tacticus]

shame it took years to get bookmarks in.

[deepsun]

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.

[locknitpicker]

> 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.

[BeetleB]

> 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).

[locknitpicker]

> 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.

[marcher]

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.

[voidnap]

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.

[locknitpicker]

> 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.

It goes a little deeper than that. Prospective Mercurial users who wanted a specific feature were first greeted with claims that they were in the wrong for even entertaining the idea they needed such a thing. The rationale was that Mercurial already did everything they could possibly wanted to do, and so by definition wanting to do something differently was proof the user was in the wrong.

But to stop hearing about how feature X or Y was needed, they could roll out their own extension and leave the project alone and not bother them with these silly things.

Shipping extensions by default is an absurdity, once you think about it. It's effectively a way to disable features by default and stop hearing about how the project needs to support a feature. And that's how Mercurial dealt with it's potential user base.

[amluto]

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.)

[somewhatgoated]

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)

[gmueckl]

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.

[blagie]

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.

[t43562]

It had a much better GUI in 2009 (THG) and I think today the GUIs for git aren't really better - probably worse.

[amluto]

“Far better tooling” means that you don’t need to do git help reset and try to remember each of the nonsensical choices, for example.

[somewhatgoated]

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.

[pitkali]

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.

[ajross]

> What does “far better tooling” mean exactly

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.