1. 4

    I feel like the opposite question is equally valid. Why do you use git over mercurial?

    1. 4

      Here’s my perspective. I think the adoption of git skyrocketed with github. I know that some hardcore devs have been using an SCM for a while, but the average web dev was largely just copying files locally and uploading files up to their servers via FTP. SVN was around and I had used it a bit, but branches were a pain, and I remember the tooling wasn’t great at the time either. When github came along and was a really slick collaboration platform that happened to use git exclusively, all of my peers just picked up git because github was so good.

      I never have used mercurial, but I think regardless of the benefits of mercurial, it just didn’t have a shot at the same popularity because there wasn’t a platform that really changed the way people collaborate like github. I would guess that if a platform like github was built around mercurial at the same time, it may have had the same level of adoption.

      I know that the github folks were really into the benefits of git at the time, but I believe the magic was in the platform not the SCM.

      Long answer short, I don’t use mercurial because none of the companies I have worked for ever have, and on my personal stuff I just use git because I know it.

      1. 3

        When github came along and was a really slick collaboration platform that happened to use git exclusively, all of my peers just picked up git because github was so good.

        That’s one of the most interesting points about the popularity of git - it’s used by many people who would never have thought of using an SCM before, from web developers to ops people. Even stranger, to me, is that for all its power git has a worse UX than what was there before - CVS, Subversion, even RCS, are all relatively quick to learn and easy to use. git isn’t either of those (and I say that someone who likes it, for certain values of “like”), yet it’s seen huge adoption. This is due in no small part to Github, for sure.

        IMHO, the influence of git on software development cannot be understated - I think it’s made SCM something every developer needs to know and master, rather than a set of niche concepts. And that’s a Good Thing.

        1. 2

          It probably also helped that some of the people involved early on with Github promoted Git heavily, going to such lengths as the “why Git is better than X” stuff and the actual git-scm.com website. Previously, you had to go to some part of the Linux kernel website to learn more about Git.

        2. 4

          I feel like the opposite question is equally valid.

          I don’t. Mercurial is so tiny compared to git that it needs justification. You don’t need to justify git, since it’s just the default. Everyone uses git, there’s tons of things built on top of git, and git is just the way things are. There’s no reason to convince anyone to use git instead of using hg, since they are way, way more likely to already be using git instead of hg.

          It’s not like we have to tell GNU/Linux users that they really should be using Windows/macOS or tell BSD users that GNU/Linux is what they really should be using. The minority users are almost certainly already aware of the advantages of the majority software but decided to stay with the minority software regardless. It’s only the other direction that really requires a defense.

          1. 3

            You don’t need to justify git, since it’s just the default

            I think you always need to justify the default. If you can’t justify the default then you’re literally just cargo culting without actually evaluating the tool or its alternatives.

            But following that argument, there are almost certainly people who use mercurial because it’s the default where they work, and where they first worked, and have never felt the need to use git, or tried it and didn’t like it because it was mildly different from what their default was.

            1. 3

              You don’t need to justify git, since it’s just the default.

              Is this the default mode of thought around here? New to the site, just curious.

              1. 1

                I just meant to say, the Glory of Git is a very well-known song. Give us a chance to sing the Harmony of Hg.

            2. 2

              Sure, you have a point. In my case I use git because most other people I have worked with use git. jordiGH said a few months ago that “the userbase is dwindling, but the development, if anything, is speeding up”, so being proficient with git is a must for me since I am a freelancer. I need to know how to use tools my clients use, even if I don’t love them.

              In 2006 or 2007 I moved from SVN to mercurial and I really liked it. However, almost no client or job I could find used mercurial, so I had to learn git. In addition to that, the boom of github made me stay comfortable with git. Nowadays, being picky about tools I am checking if other devs that have a similar mindset to mine are using mercurial instead of git.

            1. 2

              The fact that git checkout <folder> and git checkout <branch> overlap is a pretty extreme example of nonsense with git.

              I’d be very interested in seeing a similarly bungled API decision in hg. hg has always given me a better feeling for this reason, and I don’t really get to use hg that much.

              1. 1

                There’s a couple of embarrassing quirks in hg’s interface.

                Every command that takes revision numbers (commit hashes, bookmarks, tags, branch names, revsets; all are equally valid arguments) as an argument, takes it as --rev which can be shortened to -r… except for hg status for which -r expands to --removed, which shows you only removed files. You have to use the long --rev for hg status. Due to backwards compatibility, this can never be changed.

                Another emabarrassment is copying commits around from one part of the DAG to another. Canonically, this is supposed to be the hg graft command which replaces the deprecated hg transplant command. However, hg rebase also has a --keep (original commits) option that accomplishes copying, and the options for hg rebase are different than for hg graft, e.g. different flexibility in modifying authors, commit dates, branch names, or folding the result into a single commit. I would like to enrich hg graft’s feature set and deprecate hg rebase --keep. In Mercurial, deprecation just means that the feature is not exposed in the default help text, but it will never be removed.