6 ms·

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

• loeg 5mo ago
  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).
  • dijit 5mo ago
    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.
    • IshKebab 5mo ago
      > 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".
      • deleted 5mo ago
        [deleted]
      • mk12 5mo ago
        The Mercurial project has been incrementally rewriting core operations in Rust for several years now. As Pierre-Yves says in the talk, you can do an hg status on a million-file repo in 100ms. I rewrote hg annotate (aka blame) in Rust last year.
        • loeg 5mo ago
          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.
          • andrewshadura 5mo ago
            There was no headache. The migration was extremely smooth.
            • loeg 5mo ago
              I genuinely can't tell if this is sarcasm or a Python3 true believer.
          • 59nadir 5mo ago
            While I agree that Mercurial probably lost a ton of users for not clearly addressing performance issues for quite a while, I've found it's never too late to switch from using git, to be honest. I am personally using Fossil for all of my projects and it's been a great experience overall. I didn't have particularly challenging needs when it came to git so I wouldn't say that it's been a major headache overall for me, but I also think Fossil just is better as a default than git for everything that I do (and everything I've ever worked on): - Assume we want to sync to main repo as a default when issuing operations, keeping us in sync more often and easily - `commit` just commits all indexed files with changes, no need for staging - Worktrees by default (admittedly this is more of a convention and you can certainly do the same with `git worktree`, but it's very prominent in how they show you how to use Fossil). - `fossil ui` for having your own mini-GitHub is great, and having changes you make there sync with your remote is incredibly convenient. - `fossil serve` on your remote is a great way to make your mini-GitHub an actual persistent service. I've used SSH remotes for `git` but as far as setup goes this actually is a close second in terms of convenience. Nevermind setting up a more involved forge; `fossil serve` is overperforming for what you get by a lot here. All in all switching to Fossil after a ton of time using git has been a great experience overall.
    • Xirdus 5mo ago
      > Starting with C was great for performance of Git Isn't the entire git rebase logic written in Bash scripts? Or was originally?
      • jamesfinlayson 5mo ago
        Possibly? I'm sure I read that the first "release" of git was five barely documented binaries that could be strung together to do version control.
  • t43562 5mo ago
    I thought it was enormously better because it helped you not to cut yourself with all the dangerous things in a way that git didn't. It also had an excellent GUI (thg). It was a much less stressful tool to use and git hasn't really got much better since then - I've just converted a repo to git and the team using it have had about 4 unpleasant mistakes in the last week as they adapt. As for speed.....I cannot say I ever noticed any problem. Waiting around for the version control system has never been an issue for me.......except a git repo with 70,000 commits and we worked out how to merge a lot of those to fix the problem.
    • fooker 5mo ago
      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.
      • throw-the-towel 5mo ago
        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?
        • Arainach 5mo ago
          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.
          • fooker 5mo ago
            Not just mistakes though, the power of git is being able to undo anything you do with git. If you’re claiming to have never needed any kind of undo functionality, you probably don’t even need a version control system :)
  • Arainach 5mo ago
    How do you consider the UX "nearly identical" or "arguably worse"? The Mercurial CLI has clear, well named commands that are predictable and easy to memorize. hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively. The Git CLI requires you to understand its internal data structures to understand the difference between a rebase and a merge, and most people still can't explain it. I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times.
    • loeg 5mo ago
      > How do you consider the UX "nearly identical" or "arguably worse"? The core concept is similar -- history is a stream of content-addressed commits. Concepts map almost 1:1. git does some things arguably better. > hg histedit is clean and easy to use and visually shows you what is going to happen - what the new order will be - nondestructively. hg histedit is basically identical to git rebase -i. The names are different, but the operations end up being more or less the same. hg amend -> git commit --amend. Graft -> cherry-pick. > I've worked with Mercurial for 5+ years and no one on my team has ever given up on a client and done rm -rf to start anew. Every single git user I've talked to has done that multiple times. I don't know what to tell you. I've also worked with Mercurial for 5+ years, but I've never rm -rf'd a git repo.
      • kccqzy 5mo ago
        > history is a stream of content-addressed commits Not quite true for mercurial. You also get stable identifiers for commits that remain the same even after being manipulated such as after rebases or amends. It also enables tracking the evolution of a changeset which then enables `hg evolve`. Being content addressable isn’t a desirable feature in a user-friendly version control system. Who cares about it? Giving stable identifiers to commits is a much more needed feature.
        • anal_reactor 5mo ago
          You mean "git tag"?
  • BeetleB 5mo ago
    > The UX is almost the same as git, I've used git and mercurial for roughly the same amount of time. Your statement is, frankly, something that makes me question your sanity. They're not remotely similar. Outside of something like Perforce, I've not used a VCS with a worse UI.
    • justin66 5mo ago
      > I've not used a VCS with a worse UI ...than git? than hg?
      • BeetleB 5mo ago
        Than git.
    • deleted 5mo ago
      [deleted]
    • zeroonetwothree 5mo ago
      I’ve used both in parallel for 10 years or so. They are very similar, I find no problem switching back and forth
      • koonsolo 5mo ago
        I can also switch back and forth between JavaScript and C++. Doesn't mean they are similar. Conceptually, branches in git and mercurial are worlds apart.
  • kccqzy 5mo ago
    I’ve never met a single person who can use git to move a commit and its descendants from one parent to another. This requires using the extremely unintuitive `git rebase --onto A B C` invocation. The only exception are magit users who are dealing with a much better interface and a better name (magit calls it rebase subset rather than onto). In contrast every single mercurial user I know can intuitively use `hg rebase` with its `-s` and `-d` flags. That’s one giant difference in UX.
    • fingerlocks 5mo ago
      You need to say “ i’ve never met anyone who could do that in one single command line invocation”. It’s trivial to separate that result into two or more steps using bare primitive git commands and perhaps a temporary branch. You don’t need to memorize every esoteric flag if you understand the fundamentals and don’t mind spending 15 extra seconds to execute multiple commands
      • kccqzy 5mo ago
        Okay so the same operation with git is an esoteric flag but it’s easy in mercurial. Got it. Which has the better UX then? > It’s trivial to separate that result into two or more steps Okay first, tell me how to separate it into two or more steps. Second, tell me why a single operation in a user’s mental model needs to be split into two commands. The user is thinking about moving a commit and its descendants from one place to another; why should this seemingly atomic operation be split.
    • imron 5mo ago
      > This requires using the extremely unintuitive `git rebase --onto A B C` invocation. Unintuitive yes, and I'm not going to disagree with you on UX, but it's not a particularly difficult thing to learn if you use a rebase centric workflow and this is a command I use daily. P.S. don't forget to use --update-refs (or add to your .gitconfig) ;-)
    • Mashimo 5mo ago
      Is that a common usecase? I think the way I would do it, is to go to target branch, cherry pick the commits and push. Then go to source branch and revert the changes. All done from within the IDE. Not the cleanest way, though.
  • koonsolo 5mo ago
    In Mercurial, a branch is a branch. In git, a branch is not really a branch but a pointer. So already the naming in git is very confusing, and conceptually it clearly is very different from Mercurial because of this reason.
• smartmic 5mo ago
  Can't comment on Mercurial, but "for all my personal project where I don't need to care what anyone else thinks" I am using Fossil. Ever since that decision, I've felt a bit, well, held back, or rather, I don't feel quite as comfortable as I do at home when I have to use Git.
  • nsvd2 5mo ago
    I've always been interested in Fossil, especially how they handle all the things in a project that aren't strictly code but still need to be tracked.
    • giraffe_lady 5mo ago
      I'm like the person you responded to, I've just used fossil personally for years after working at a place using it a while back and always liked it. This is its moment though. It is so well suited for LLM coding tools. You can jam all the markdown context, skills etc into the wiki. The CLI has wiki and ticket tools so those are just available for it to use. Fossil does not mind if you use the repo DB for your own stuff, so you can log all your sessions in there, fts5 is plenty for as needed on demand retrieval. Big changes to professional development over the last year and hard to predict how it will all shake out, but I think the tooling will converge on something that fossil already has all the structure for. I was a late adopter on LLM-assisted coding but already feel ahead of a lot of my peers because of how easy and effective this approach is.
    • spit2wind 5mo ago
      If you're talking about binary files, then it has similar limitations to Git and Mercurial, AFAIK. Fossil, git, and Mercurial are not really designed for large binary files. Otherwise, in Fossil, any text is just another artifact. Wiki pages can be stored as files in the repo ("embedded") and versioned in the same manner as code files (that is, exposed through the same interface), or tracked behind the scenes (in a separate database, IIUC, with a different interface). Tickets and forum entries are also tracked and versioned similarly to non-embedded docs. Aside from everything being versioned, the visibility of the objects is quite good. The user interface, both command and web, is light-years better than anything Git related. I highly recommend you check it out. Even if you find it doesn't meet your needs, many of the design decisions are instructive. I find it quite inspiring.
• F3nd0 5mo ago
  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.
  • toomim 5mo ago
    If you like darcs, try Pijul. It's darcs' spiritual successor, and quite performant and capable.
• nezi 5mo ago
  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…
  • bsder 5mo ago
    > 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 on git repos before any operation that is slightly weird knowing that I may put the repo in some state that I cannot easily unwind. I never did that for Subversion. I never did that for Mercurial. I don't do that for Jujutsu. Those are all sane UX. Side note: Thankfully AI is REALLY good at telling you how to un-wedge your git repo. That should tell you everything you need to know about Git UX and why you should avoid Git.
    • funimpoded 5mo ago
      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.
      • imron 5mo ago
        > Not any more. `git add -p` FTW
    • JuniperMesos 5mo ago
      I find staging useful even in small projects. I've been deliberately experimenting with jujutsu for the past year or so in various projects, and one of the workflow differences that I noticed most readily with jujutsu was the lack of a staging area. It took me a while to get used to that.
• aidenn0 5mo ago
  My recollection is that it was more of a VHS vs Betamax story than one being strictly superior. When a lot of people were making their decisions, Git was a lot faster in ways that mattered. IIRC, shortly after a lot of places picked Git, Mercurial cut a release that significantly improved performance.
• pitkali 5mo ago
  Mercurial had an easier to use command line interface. If that's what makes it far better technology, we have a very different idea what makes the "technology" better.