I sincerely hope jj gets the recognition it deserves in coming years.
Mercurial, 20 years and counting: how are we still alive and kicking? [video]
61–70 of 263 posts
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#62Earlier quoted context omitted.
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.
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).
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.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#63Earlier quoted context omitted.
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 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)
> 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.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#64Earlier quoted context omitted.
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).
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 performa…
> Writing your tooling in python is valid while starting out and prototyping.
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".
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#65Earlier quoted context omitted.
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 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.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#66Almost 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 pe…
> I helped them make the wrong choice, Mercurial.
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.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#67Earlier quoted context omitted.
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 r…
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)
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#68Earlier quoted context omitted.
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. It’…
There is an initial cost to learning hg, but it is usually offset by the less destructive nature of hg's behaviors and defaults in the long term.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#69Almost 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 pe…
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. Unfortun…
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 :)
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#70Mercurial 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.