1. 52
  1.  

  2. 4

    It is great to see more services supporting dvcs other than git. Can someone who prefers to use Mercurial share some.of their experiences wirh it and what makes it better for them? Not trying to start a flamewar, just being curious about it

    1. 17

      I’ll just C&P and update the last time I wrote what was so awesome about hg:

      Here’s a list of Mercurial features that I think are really cool:

      • Revsets – a domain-specific language for querying your commits
      • Filesets – a domain-specific language for selecting files
      • Templates – a domain-specific language for altering the output of almost every command. Putting these together you can do things like this.
      • Evolution – a distributed and safe way to share rewrites (think automatically recovering from upstream rebase without any git reset –hard and no git push –force).
      • Absorb – automatically amends an entire stack of WIP commits at once by picking the right diffs from your working directory based on which commits’ contexts they fit best.
      • Curses interface for hunk-picking – a unified interface for splitting diffs for any purpose: whether to revert working-directory changes, write a new commit, uncommit parts of a commit, or amend a commit with more diffs. Just add –interactive to any of those commands and start picking hunks!
      • Curses interface for redrafting your commits – think git rebase -i with a curses interface (this is quite new, in the lastest relase; I’ve made a few UI tweaks to it that should show up in the next release)
      • A fairly rich built-in web interface – hg serve and point your browser to http://localhost:8000 and you’re good to go.
      • Lots of support for monorepos – indeed, this is the main reason that Google, Facebook, and Mozilla are all pouring work into hg and are using it.
      • A consistent UI – this one is more subjective but often-touted feature of Mercurial. If a command accepts a revision/hash/tag/bookmark; it always uses the -r/–rev flag for it (and you can also always use a revset for any command that accepts a revision). If a command allows hunk selection, it always uses the -i/–interactive flag for it. The help for every command fits in about a screenful; no never-ending man pages full of arcane flags and explanations you don’t understand nor care about.

      Give it a try! Mercurial is neat!

      1. 4

        For 90% of your workflow, there’s no big difference. The other 10% can be painful to get used to. For instance, Mercurial does not have Git’s concepts of “staging area” and “tracking branch”, which simplifies things.

        I’m more comfortable with Git purely because I’m used to it but I’ve recently taken a liking for Mercurial. It feels sturdier and more consistent.

        Edit: I forgot to mention that Mercurial is very modular. Not only are there various extensions to simplify your workflow, you can write your own extensions to suit the needs of your project.

        1. 2

          mostly a sane UI/UX. But also it’s easily extensible with python, and it has neat things like revsets.

          1. 2

            I wrote an article about it, to copy/paste some relevant parts:

            My chief gripe with git is its user interface. With ‘user interface’ I mean the commandline user interface. Let me show by example:

            $ git help commit | wc -l
            506
            $ hg help commit | wc -l
            59
            $ hg help commit -v | wc -l
            96
            

            Currently my git installation has 169 “core” commands:

            $ find /usr/lib/git-core -maxdepth 1 -type f -executable | wc -l
            169
            

            Compare this to mercurial’s 50 built-in commands (from hg help), a number which has remained constant since I wrote this article (whereas git had 160 commands when I first wrote this 2 years ago).

            “But git commit has so many more features”, well, perhaps. But how many of those are actually used by most users? Mercurial can be easily extended, and most “missing” features are implemented in extensions (many are shipped with the base mercurial install). For better or worse, git is bloatware, and like most bloatware it comes with a [notoriously difficult to understand manual][git-man].

            Mercurial has a manual and user interface that I understand without too much effort, and this is by far the biggest reason I much prefer mercurial over git. If I need to know something from mercurial I can just read the documentation and go ‘ah’, with git … not so much. There’s a reason so many of the [top Stack Overflow questions][so-top] are about git.

            Some might say (and indeed, have said) that I’m lazy and just need to spend more time and effort learning git. Well, perhaps, but the thing is, git doesn’t really do anything. Unlike a programming language or API I can’t really build anything with it. It’s merely logistics to facilitate the actual building of stuff.
            It seems to me that ideally you want to spend as little as possible time on logistics, and as much possible time on actually building stuff. I know enough git to get by, but not enough to deal with rare exceptional situations that occur only a few times a year.

            1. 1

              Broadly, they both have comparable functionality (at least for what I need), but mercurial is more friendly where git is more flexible. By and large, hg stops you from doing things that you probably don’t want to do, and makes the most common actions easy.

              That said, I switched to git a few years a back and am happy with the move. It seems trivial, but one thing that I prefer in git to hg is the ability to manipulate branches. In git a branch is just a reference to a commit, and so can be moved, renamed, deleted. In hg branches are a core part of how the repo is structured and can’t be changed. If you use a feature-branch strategy, this leads to either a) a lot of old, essentially dead branches or b) hacky workarounds using bookmarks.

              This is somewhat indicative of the overall experience - hg is simple if you use it the expected way, but gets messy otherwise. Git is always a bit fiddly but is far less prescriptive.

              1. 2

                The hg analog to a git branch is called a bookmark. The difference in nomenclature is unfortunate and an artifact of history but the same functionality exists.

                1. 1

                  Yes, I know. I mentioned bookmarks in my reply. Perhaps it’s just my experience, but bookmarks (especially when used in conjunction with branches) tends to be rather clunky compared to branches in git.

                  1. 2

                    I don’t know very many people who actually use the hg branch feature. Pretty much everyone just uses bookmarks. I don’t personally find the clunky but they’ve been improved quite a bit since their first appearance. They are pretty close to a one to one match with a git branch for my needs.

                    1. 1

                      In fairness, I haven’t used hg for around 5 years (maybe longer). Back then, hg branch was idiomatic - we tacked on bookmarks to our workflow to handle temporary branches, but it was never smooth.

            2. 3

              Woohoo! I’ve been using sourcehut’s hg beta and it’s been thoroughly great. Or at least on par with the rest of sourcehut, which is a little rough around the edges but a very solid core. Which is great for me, since that’s what I like. Might be time to ditch GitHub for reals.

              1. 3

                I can see how sourcehut is becoming a gitlab competitor for open source projects. Mailing lists are huuuuge.

                1. 1

                  That said, it’s expected to become paid at some point, no? Or has that changed? As much as I fully respect and understand this decision, i.e. that infrastructure and @sircmpwn’s work is not running on pink ponies farting rainbows, I’m kinda afraid of it creating a barrier for potential contributors to my open-source projects in future, in case of people who can’t afford a subscription.

                  edit: Or, of missing on network effects and random (potentially brilliant) forks in case I were to host my own instance.

                  Sorry for this sounding FUD-ish, I just don’t know how to phrase it in any other way.

                  1. 3

                    You won’t need a subscription to contribute to projects on the platform, and if you can’t afford a subscription you’ll receive a subsidized account.

                    edit: Or, of missing on network effects and random (potentially brilliant) forks in case I were to host my own instance.

                    Does this happen? In any case, contributions can move across sourcehut instances.

                    1. 1

                      If hosted version is used then yes. Of course server costs must be paid by someone. However, self-hosted version of sourcehut is complete, in comparison to gitlab open-source core model.

                      1. 1

                        During the alpha, free accounts are not limited in any way. After the alpha, free accounts will not be allowed to own resources, including git repositories, bug trackers, mailing lists, etc, nor submit builds on builds.sr.ht. They will, however, be able to contribute to projects maintained by paying users.

                        https://man.sr.ht/billing-faq.md

                        So, contributors could just make a free account and contribute to your projects.

                    2. 2

                      Great work! Another vcs I’d recommens is darcs, but I’m not sure how easy it is to work with without haskell.