Mercurial is so, so slow. It is painful to use.
Mercurial, 20 years and counting: how are we still alive and kicking? [video]
141–150 of 263 posts
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#142Mercurial 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…
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.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#143Earlier quoted context omitted.
The dangerous parts of git exist to make it trivial to undo mistakes. You don’t have to use those for your regular workflows. With any other system, your only option is usually checking out a fresh copy from a server or backup.
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.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#144Earlier quoted context omitted.
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 assignin…
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.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#145Earlier quoted context omitted.
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.
There was no headache. The migration was extremely smooth.
I genuinely can't tell if this is sarcasm or a Python3 true believer.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#146Mercurial 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…
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.
What does short lives branches even mean? Make a branch, close it, or merge it.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#147Earlier quoted context omitted.
> But I guess I couldn't read the future in terms of which one would win out! 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…
To be entirely fair nothing in git backend prevents someone to make friendlier frontend.
Case in point is Magit, I use Mercurial almost every day at work so git got a bit unfamiliar, but Magit is still more natural then mercurial for me.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#148I should write a whole article about this.
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.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#149Earlier 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.
And in a similar vein, Darcs. It unfortunately couldn’t compete with Git on performance, but the user experience is on a whole another level.
If you like darcs, try Pijul. It's darcs' spiritual successor, and quite performant and capable.
Re: Mercurial, 20 years and counting: how are we still alive and kicking? [video]
#150Earlier quoted context omitted.
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…
> 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 o…
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.