1. 27

  2. 24

    Git is powerful. Even now, at version 3.1 hg help log lists about a dozen of options; git help log gives me about 60 pages of documentation.


    1. 11

      Wow. How could one think that was an argument in favor of git?

      1. 4

        Lots of documentation is a bad thing?

        1. 7

          No, not at all. The point is that git-log has many many not-quite-orthogonal flags, whereas Mercurial has fairly expressive query and template languages that obviate such flags. An example is the revset “grep” operator, instead of git log –grep. The former can then be used anywhere a rev-like is accepted, whereas the latter is only useful on log and has to be documented how it behaves with respect to other flags (at least on some level). Does that make sense?

          (One of the things that came out of that thread is fixing some docs and making some things more discoverable.)

          1. 4

            A git query language is a great idea and should be stolen from the hg guys. -G, –grep, and pickaxe could all be generalized.

            1. 2

              Fair enough, yeah. Most of my work is writing docs, and most of my free time has been in ecosystems where the docs are terrible, so I’m more likely to be like “oh thank God” when I see a bunch of things. :)

              1. 4

                I think the main problem with the git man pages is that they’re too extensive, overwhelming the curious user with extraneous information. I’m not alone in this opinion I think given the existence of http://git-man-page-generator.lokaltog.net/

                1. 7

                  It’s also “information” that’s not explained. There are a lot of places where they reference some non-obvious concept by its name, and there’s no cross-reference to tell you where to learn what it is, and if you Google the phrase it turns out this is the only occurrence anywhere, ever.

            2. 3

              Yes. :)

              Probably depends if you say things like “there’s so much to learn!” with a grin or a grimace. It’s (sometimes) a proxy for the complexity (difficulty) of using a tool. It makes it harder to find the option I want. There’s a cognitive load because I have to look at each option and decide whether it’s for me or not. Assuming even only a single yes/no per page, that’s 60 decisions. I’m exhausted.

          2. 7

            Yeah; I helped Augie draft this response. I think we both took some SAN damage over the course of this thread.

            1. 3

              I’m pretty sure git’s help just opens you to the manpage rather than a terse briefing.

            2. 20

              Mercurial (or an extension)

              That is why teams I have worked on have avoided Mercurial. Because, you don’t use Mercurial – you use Mercurial + Extension Soup.

              “So… I just grab git and I can start working” “Yep.”


              “So, I just grab hg and I can start working” “Not exactly, you will need to enable some of the native extensions, and then you need to grab attic, bfiles, caseguard, checkfiles, checkmeta, codesmell, collapse, contains, … (30 more extensions)”

              … ugh. I understand the positive idea of an very extensible dvcs, but I have been in the room when that feature killed off hg use multiple times.

              1. 8

                I’m honestly a bit confused by your comment. You’ve really got two comments, which I want to treat separately:

                1. You need to enable a pile of extensions in Hg to make it work like Git (which is usually what people mean when they say they need extensions to make Hg “usable”)
                2. Having an extensible DVCS that ships with extensions is a bad idea

                To the first, the main extension class that Mercurial ships with disabled by default are history editing extensions. That’s it. All the other Git workalikes are there. This is done so that new users cannot accidentally obliterate their history and get into a weird state. I’m going to suggest that if a user adding a line that says histedit= to their configuration file is too complicated for them, then they probably should not be dynamically rewriting history in the first place. Lots of programs do something similar (usually labeled as something like “enable advanced mode”).

                Beyond that, though, extensions have been great for Mercurial. First, it helps development: team members frequently develop new functionality as extensions, then land the extension in Mercurial to see if others can take advantage of it, and then fold it into core if lots of people find it useful. That’s how caseguard (one of the only things in your list that is an actual extension) happened: the team I was on wanted to know when we were making files that could not be opened on Windows, so we wrote an extension and donated it to Hg; they shipped it as an extension and found it really useful; and it landed in core a release or two later. Bookmarks (Git-style branching) landed the same way. A curses-based improvement to record (diff hunk selection) was also developed that way.

                And sometimes, it’s really useful to have legitimate extensions that you do not turn on by default. The other extension you list that is real, bfiles, is a really old version of largefiles, which ships with Mercurial but is disabled. largefiles allows storing large files outside of Mercurial proper, similar to Git’s attic and lfs packages, and so is definitely a sometimes food. But unlike those packages, because largefiles is an extension and can hook deep into the underlying machinery, it can interact cleanly with Mercurial’s existing commands and existing user aliases out-of-the-box. To use lfs in Git, you have to either use a bunch of additional commands, or set up a bunch of custom aliases and hooks to keep things synced. Doable, yes, but adding a single line to your Mercurial config is a lot simpler.

                I sometimes wish Mercurial would fold extensions into core faster for selfish reasons, but I think Mercurial having, and making use of, extensions, is not a good reason not to use the tool.

                1. 4

                  I didn’t intend it to be confusing. I have been lucky enough to be involved with a great deal of greenfield development, back to the point when version control systems are decided on. I have repeatedly seen “extensions” (and the complexity in choosing / enforcing use) be the reason teams decided not to use mercurial, that is all… that was my entire point.

                  As for the extensions, I haven’t used mercurial in years, so I just grabbed random extensions from the list found ( https://mercurial.selenic.com/wiki/UsingExtensions ) to create my obviously mock example. I gave up on mercurial after losing too many battles (way back when git on windows was useless)… and I simply couldn’t get buy in.

                2. 5

                  The extension system is optimised for people learning Mercurial who do not come with git preconceptions. The size of this userbase is larger than you may think. Personally, when I have taught Mercurial, I see that most beginners are happy to learn that they can do something if they just enable it. They never seem to be upset about enabling something they didn’t even know about.

                  It is only when someone comes from git and wants to start rebasing, cherry-picking, and splitting hunks right away that they feel thwarted by having to enable extensions. Would you be satisfied if you only had to flip on a single switch and thus enable all of those extensions? I might write a patch to do that.

                  1. 2

                    I haven’t advocated for Mercurial in years, so I am not the best one to ask. I gave up on it after having extensions, popularity or github thrown in my face enough times. That said, for teams that want a git equivalent experience without having to toggle a group of extensions, having a gitsimilar switch or something might be very useful. Again, the major concern isn’t one extension… or one switch… it is an endless set of “decisions” to be made, it is decision anxiety or decision fatigue.

                    If https://mercurial.selenic.com/wiki/UsingExtensions is up to date – “out of the box” you have to make 30 yes/no decisions on extensions. Now, you might claim “use vanilla and only add stuff as you need it!”, but teams see those as “bundled” and consider each one a yes/no decision. Extension Soup!

                    1. 2

                      Personally, I prefer Mercurial and have never really found enabling an extension to be a chore – besides, I figure some one could just copy a fully loaded .hgrc from someone else if they want.

                      That said, perhaps another approach would be for Mercurial could take a page from Emacs' book. Emacs has an analogous concept of “disabled commands.” If you try to invoke one of these you get a message like the following:

                      You have typed RET, invoking disabled command upcase-region.
                      It is disabled because new users often find it confusing.
                      Here's the first part of its description:
                         Convert the region to upper case.  In programs, wants two arguments.
                         These arguments specify the starting and ending character numbers of
                         the region to operate on.  When used as a command, the text between
                         point and the mark is operated on.
                         See also `capitalize-region'.
                      Do you want to use this command anyway?
                      You can now type
                      y   to try it and enable it (no questions if you use it again).
                      n   to cancel--don't try the command, and it remains disabled.
                      SPC to try the command just this once, but leave it disabled.
                      !   to try it, and enable all disabled commands for this session only.

                      One could imagine Mercurial taking a similar approach: explain that the extension is not currently enabled for safety reasons, show a bit of the help text for it, and then give a choice to go ahead anyway, go ahead and also enable it in the .hgrc, or cancel. (And possibly enable it or all extensions for a limited time, similar to sudo).

                      1. 2

                        It basically does this already:

                        $ hg rebase
                        hg: unknown command 'rebase'
                        'rebase' is provided by the following extension:
                            rebase        command to move sets of revisions to a different ancestor
                        (use "hg help extensions" for information on enabling extensions)
                        1. 1

                          The “chore” is two part. The first is DECIDING if you want to use an extension, and if it becomes critical to your workflow, if you want to force all other team members to use it. The second part is acquisition of non-included extensions and forcing your team to go through the acquisition process (more complex than just making a copy of a .hgrc).

                          1. 1

                            On the 2nd part, is it really common to use extensions not bundled with mercurial? I could be way off, but the only extensions I’ve seen in use are the ones that ship with the default install, in which case it’s only a matter of enabling them in the config, not a separate installation process. I agree that using non-default, third-party extensions would raise the barrier to entry to your codebase, not to mention odds of something breaking during an upgrade. The docs even mildly imply that you might want to be cautious about using third-party extensions, because: These extensions are not distributed together with Mercurial. The Mercurial project provides no guarantees about these and does not maintain or test them. Note that Mercurial explicitly does not provide a stable API for extension programmers, so it is up to their respective providers/maintainers to adapt them to API changes.

                            1. 1

                              On the 2nd part, is it really common to use extensions not bundled with mercurial?

                              There are hundreds of 3rd party extensions, so I would hope at least some of them are in use. Additionally, as extensions are the feature I have seen be the deciding factor AGAINST Mercurial… it would be depressing if all the work of developing and supporting the feature was only intended to be used by included extensions… which could just be “features” at that point.

                      2. [Comment removed by author]

                        1. 11

                          I’m sorry, but I’m getting really frustrated by people who are saying “I tried Mercurial eight years ago and it sucked” replying to threads like this.

                          Git eight years ago was also a different beast. In modern Git, you can git co somebranch, and, if somebranch exists on origin, will automatically track that. Git eight years ago did not: you had to explicitly create the branch, then fix its tracking. Even if somebranch does not exist upstream, modern Git will track the branch you just came from, which is usually what you want for feature branches. But Git eight years ago did not: you again had to explicitly set it.

                          Git eight years ago did not have git rerere. Git eight years ago did not have many of those 60-odd flags to git log that another commenter here loves. Git eight years ago did not work on Windows in any meaningful sense. Git eight years ago had no good GUIs. Git eight years ago required you run git gc as a cron job because Git never did incremental GC “when it was needed”.

                          But it’s not eight years ago. It’s today. So if we’re going to talk about what is good about Mercurial, and what is good about Git, and what is bad about Mercurial, and what is bad about Git, then can we please talk about the current versions of both of those tools?

                          Maybe I’m really biased and Mercurial is just actually inferior to Git. I don’t think so, but that’s entirely possible. But the one thing that I’ll readily grant is that Mercurial 1.0 was inferior to Git 2.5.2. And Git 1.0 was inferior to Mercurial 3.5.1. So, please, let’s at least compare the tools we have today when we’re having these discussion.

                      3. 11

                        I use Git for all of my personal projects and collaborating with people on open source stuff, but at work we use Mercurial (and Kiln), so I’ve had a chance to use both systems quite a bit

                        Git may have a million options and can be very complicated, but all of the basic stuff that I need on a daily basis works out of the box the way I expect it to, so actually using it feels very simple.

                        With Mercurial I always feel like I’m jumping through hoops to make it work how I expect and make it do what I want. The end result is that in practice Mercurial feels more complicated and less intuitive.

                        In fairness to Mercurial, I should point out that my view is biased by Kiln, which has its own weird way of doing branching hacked on top of Mercurial, and has been generally a big pain to work with.

                        1. 5

                          Kiln has a really weird take on Hg, but you can use Git-style workflows with Kiln easily, too. The Kiln team itself did that before I left, which was two years ago at this point.

                          If you can reference a specific workflow or task you were doing that you found complicated, I’d love to hear it. If there are broken things, that’s useful feedback, and if Kiln’s odd way of doing branches was the problem, I’d love for you to think of that as a Kiln issue instead of a Mercurial issue.

                        2. 8

                          I expect to get a lot of flack for my thoughts but I’ll be brave and post them anyway.

                          1) I think git owes a lot of its popularity to the fact Torvalds was part of the project.

                          2) I think a lot of the “usability” issues of mercurial and its workflow stem more from people trying to make it git when it isn’t. Also, If I remember correctly, when git and mercurial were both newish the arguments about which was easier to use were in favor of mercurial… not git. I admit I tire of the go lang people saying that but I do believe it’s true.

                          3) As far as feature parity goes, IMO, they’re really on par with other.

                          4) Having used both at work and at home, I prefer git only because I’m used to it. With that said, if I were a major organization with a mixed development team of Windows, Linux, etc. I’d probably go with Mercurial.

                          1. 5

                            I was the tools guy for migrating a ClearCase shop to Mercurial…. we took flak from the git folks about it; I’ve heard all the standard complaints (and more!).

                            In general though, I think you’re right, but I’d add on that github has really delivered a great product with a super high standard for fit and finish, which drives git adoption heavily.

                            I’ve used and supported both git and mercurial: they are not par for features, nor for usability, nor for power use. Mercurial beats git on dang near any axis you look at…. if you’re willing to take the time to look into it. :-)

                            1. 1

                              1) Of course!

                              2) I still think “ease of use” favors vanilla Mercurial. Why would Go people say anything about Mercurial at all… it is written in Python. Did you mean Python people? Mercurial 1.0 came out 7+ years before Go 1.0. Was it because Go at one point was hosted on Mercurial? It has since moved to Git, and if I remember correctly most of the debate was around code-review systems.

                              3) With or without extensions? In theory, with extensions… Mercurial can do absolutely anything… so that would be it infinitely ahead in features – but I am not sure this is what people WANT.

                              4) Git on Windows is now (and has been for years) good enough. It was non-existent and then horrible for a number of years, but seems to have overcome that.

                              1. 2

                                As far as #2 is concerned you misunderstood what I was saying. I was referencing the fact that people who use go lang are very similar to people who use git these days and hate mercurial. The go people always tell haters if they’d use go “the go way” they’d have no reason to hate. Which is the same line people who use mercurial now tell the git people.

                                Hopefully that makes more sense.

                                1. 1

                                  Yeah, that clears it up a ton! Obviously none of my guesses where even in that direction.

                                  That said, I don’t think the criticism “you’re using it wrong” is necessarily unfair. Tools are built with expectations around use, if you use them in ways unintended – it may or may not work – but is seems fair to recommend people judge a tool when being used as expected. “This hammer is a terrible screwdriver”… “Umm, maybe you should use it to hammer things?”… “But I want to screw things!”

                            2. 2

                              This is a useful piece; it did a lot to clarify for me the philosophical difference between the two. Thanks.

                              1. [Comment removed by author]

                                1. 1

                                  There is one feature that once it’s really done and polished I am hoping will be a killer feature: Mercurial Evolve.