dragonsh 5 years ago

It's very sad to see bitbucket dropping mercurial support. Now only Facebook and volunteers are keeping mercurial alive. Sometimes technically better architecture and user interface lose to a non user friendly hard solutions due to inertia of mass adoption.

So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use. GitHub successfully marketed git, so git and GitHub are synonymous for most developers. Now majority of open source projects are reliant on a single proprietary solution Github by Microsoft, for managing code and project. Can understand the difficulty of bitbucket, when Python language itself moved out of mercurial due to the same inertia.

Hopefully gitlab can come out with mercurial support to migrate projects using it from bitbucket.

For people who believe in self hosted solution can install Kallithea (https://kallithea-scm.org) or Rhodecode open source edition. Kallithea is used by Unity engine to manage their source code internally with mercurial.

  • jjoonathan 5 years ago

    I started my distributed version control journey when SVN was still king of the hill and git and mercurial were both tiny challengers.

    I actually picked mercurial first. I found the interface more intuitive, especially coming from svn. The problem was that everyday commands were just dog slow -- 5, 10 seconds on every single interaction. It felt like wading through molasses, contrast to git, which was effectively instantaneous on small repos and git on my large repo was still multiples faster than hg on a small repo. Also, IIRC hg didn't have a "git stash" equivalent. I chose git on its merits and didn't look back.

    A few years later (2010 ish?) I met a mercurial evangelist who said things had changed on the performance front, but I checked and they hadn't.

    I'll give hg the benefit of the doubt that it eventually got better, but I have serious doubts about your accusation that git's success had to do with marketing. I gave hg a more than even chance and it lost, fair and square, on technical merit, as weighted according to my everyday use cases.

    • hyperrail 5 years ago

      Git was once fast for my use too. Then I returned to Microsoft to work on building Windows. Even after 2.5 years of improvement,[1] "git is slow" is still one of the most common complaints about the Windows engineering system.

      On my Skylake+SSD desktop, it takes over ten seconds to switch branches with git checkout, several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.

      We are making many great strides here at Microsoft to improve git performance, such as with VFS for Git which my Windows repo clone uses. But with hundreds of gigabytes in a unversioned download of the source tree, there is only so much we can do.

      [1] since https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...

      • grandinj 5 years ago

        git was deliberately designed around the "known fast" things in Linux.

        One of those is that path name lookup for certain file attributes is dirt cheap because of the dentry cache.

        Since Windows doesn't have an equivalent, git is going to be slower there.

        Hopefully the Microsoft people working on this will find ways to make git on Windows faster, since even with a much smaller repo (LibreOffice), git is somewhat painful on Windows.

        • owl57 5 years ago

          > Hopefully the Microsoft people working on this will find ways to make git on Windows faster

          WSL2?

          • xnyan 5 years ago

            my takeaway of the demo I saw on WSL2 at the Microsoft conference was basically several hours of engineers salivating over how much faster git was on wsl2

      • Arnavion 5 years ago

        >several of which are used just to calculate the "your branch is ahead of origin/your-branch-name by N commits" value.

        That one at least is fixed now, by having an option to disable it.

        https://github.com/git/git/blob/v2.23.0/Documentation/config...

        • hyperrail 5 years ago

          That git setting is for `git status`, but I think `git checkout branch` still doesn't have a comparable option either on the command line or in a git configuration file. The closest you can get is to turn off all output with `git checkout -q`.

          • Arnavion 5 years ago

            Oh yes, I just tested it out and you're right. Bummer.

      • Someone1234 5 years ago

        Definitely sounds like a problem. Do you think an alternative source control solution would handle that situation better? At some point huge with a large number of small files takes its toll.

        It would be interesting for someone inside Microsoft to write a blog describing why Git works well for the Linux Kernel but not for the Windows Kernel. They cannot be that different from a layout perspective, can they?

        • ldrndll 5 years ago

          I believe the difference is that the Linux kernel itself is not that big a project. Windows is a lot more than just a kernel; it’s more akin to having the source code for an entire Linux distribution in one repo.

          • vquemener 5 years ago

            You mean like Gentoo (https://github.com/gentoo/gentoo) ? It's not that big either (around 700MB).

            • webstrand 5 years ago

              That only includes the ebuilds, which are instructions for how to build from source, not the sources themselves.

              • vquemener 5 years ago

                So the sources for, say, Paint or Edge are versioned within the Windows repository?

                • hyperrail 5 years ago

                  Yes, most of the components and files in a default Windows installation are built from sources in the main Windows OS git repo.

                  Some parts of Windows have split out into their own repos and CI build and test pipelines, but splitting is a process that takes people's time and has pros and cons, especially when changes in the main OS repo are needed to give the separated components a complete, coherent API surface.

        • Arnavion 5 years ago

          The Windows tree is unlike the Linux tree in that the Windows tree is the entirety of Windows, not just the kernel. Not having to check out the entire tree is why GVFS was made.

          https://github.com/Microsoft/WSL/issues/873#issuecomment-425... talks about why Windows I/O for multi-file operations is slow in general (as opposed to sustained I/O on a single file).

        • usefulcat 5 years ago

          I read an article a while back about why git is slower on windows than on linux (probably linked from HN, but I can't find it just now) and the TLDR is that it's because the windows filesystem (not just NTFS, but everything around it) has many customization points, and for that reason git will always be slower on windows regardless of the particular underlying FS (as in, adding windows support for, say, ext4 wouldn't fix the problem).

    • dragonsh 5 years ago

      I started with CVS then moved to svn. From there moved to bazaar (bzr), from there moved to git and at last used mercurial and settled on it. I still keep an active look at fossil SCM.

      In my earlier team at fortune 100 firm, most developers use Windows with svn. We tried git and it did not work well due to UI and windows support. They were able to pick up UI easily and were quickly productive in mercurial. It worked pretty good on all 3 platform Windows, Mac and Linux. I am talking of time when GitHub was not that popular in corporate world.

      Performance was never an issue.

      Also at that time mercurial followed philosophy of being explicit and every merge needs to be explicit and committed with immutable history. So can see the evolution of code along with the mistakes made.

      I believe the success of git is due to GitHub and for many it's synonymous.

      • throw0101a 5 years ago

        > I started with CVS then moved to svn.

        When I was your age we used RCS and SCCS, in the snow, up hill, in both directions. :)

        Seriously, I have no doubt git has an awesome on-disk format, but whenever I use the git(1) command I want to slit my wrists. I'm sure if a developer uses it many times a day it's possible to get used to it, but as a sysadmin that only uses it sporadically, I basically do:

        * git clone

        * vi repo/some/file/blah

        * git add/commit/push

        * rm -rf repo/

        • dboreham 5 years ago

          I'm in the same camp of rm -rf'ing (and when I were a lad we did all our computing on relays...). A fun game to play when you have spare time is to Google for how to do some random thing with git then pour up a cup of coffee and read through the 17 contradictory answers on just one SO page...

        • phaemon 5 years ago

          As a sysadmin (as am I), you should know how git works so you can fix it when the devs break it. :)

          What do you find difficult about it?

          • throw0101a 5 years ago

            The format of a command is `git <action> <options>`, and the <action> is completely baffling to the RCS/CVS/SVN habits I've built up for the decades.

            For the little while that I sometimes used Hg I found it much easier to get my head around.

            It's mostly a lack of practice/use.

            • SAI_Peregrinus 5 years ago

              I just use a bunch of aliases to make sense of things. eg "new-branch = checkout -b" and "branches = branch".

        • mey 5 years ago

          Order of my exposure to SCM

            Shared windows mount
            Visual Source Safe
            CVS
            SVN
            Perforce
            ClearCase
            Git
            Team Foundation Server
          
          Of those I still use Git and SVN. Aside from the shared network drive, VSS and ClearCase are in a dead heat for the worst SCM I have been exposed to.
          • gcoleman 5 years ago

            Visual Sorta-Safe, we used to call it.

            • tres 5 years ago

              Tell bob he needs to check in the file so I can work on it.

          • stevekemp 5 years ago

            Throw in SCCS, on SCO Unixware, and Darcs, and you match my exposure too, mostly. Now I remember what an abomination VSS was - with the mandatory locking behaviour.

            • rejschaap 5 years ago

              It wasn't mandatory, actually. It was possible to turn off the locking. But that was like entering a whole new world of pain. So most people didn't dare turn it off.

              They called it "multiple checkout", and the manual strongly recommended you do not turn it on.

              The software had issues with corruption due to operations not being atomic.

              • mey 5 years ago

                The lack of atomic commits in VSS, CVS and ClearCase caused absolutely horrific problems, even on small teams.

                • silverbacknet 5 years ago

                  I remember when you basically had to yell "Committing!" and "Done committing!" to the whole room. Woe be unto those companies that tried to use VSS or CVS with more than a roomful of developers.

            • marcosdumay 5 years ago

              I can live with the locking behavior, but VSS had a tendency of corrupting the entire repo ever few weeks that is hard to accept.

              • flukus 5 years ago

                I could live with the locking or the corrupted repos if it was half decent at just sharing code, but daily we had problems where someone would check in code, VSS would say it was checked in but the person updating would get stale versions. Sometimes if you looked at the server version it be be correct but not what you would receive on a fresh checkout.

                It was literally less functional than copying to a shared drive. Of course management and other developers refused to believe that OSS solutions were better, MS ecosystem developers were an extremely insular group.

                • marcosdumay 5 years ago

                  Yes, there was that too. I've seen quite a few regressions caused by this.

          • keithnoizu 5 years ago

            I feel blessed to have started with SVN and Source Depot (msft) and only come across CVS and Perforce on rare occasions.

            • hyperrail 5 years ago

              Source Depot is very similar to Perforce since sd started as a p4 fork.

              Incidentally, I remember one person at Microsoft who claimed to be involved in the decision to adopt sd circa 1999 saying that Microsoft has the right to turn sd into a product if it so chooses. (He/she was responding to contrary claims made on an internal email mailing list which was very widely read, so I assume if he/she was misremembering or lying he/she would have been called out.) Though ultimately MSFT made VSTS/TFS version control instead, which has striking resemblances in concepts to sd/p4.

              • keithnoizu 5 years ago

                Interesting. It wasn't a bad solution at the time, being able to pass around commits was nice and more straight forward than the patch mechanism on svn. Git and Mercurial were significantly superior solutions though.

            • robaato 5 years ago

              Source Depot == Perforce

        • sciurus 5 years ago

          As a sysadmin, how do you version your infrastructure code (things like puppet or terraform)? If another VCS, cool. If not at all, try git for it!

        • seanmcdirmid 5 years ago

          Some people on the other side of the Unix/Microsoft tracks started out on sourcesafe.... shudder

          • jsgo 5 years ago

            raises hand

            dunno, I like git better, but at the time it did what our small team needed. Granted, we always ran into issues with one of us having a file locked that someone else needed, but onboarding was a breeze.

            I'm glad I use git now, but Sourcesafe was an okay introductory source control solution.

        • jbverschoor 5 years ago

          Do a shallow clone and you’ll save some time.

      • WorldMaker 5 years ago

        I started with CVS in HS on a couple SourceForge projects, but skipped svn for the same reasons I used CVS sparingly: setting up servers was too much effort, (especially for non-open source stuff), especially on Windows. Instead of svn I fell hard in love for darcs in college (after the usual college tale of losing source files the day before a project was due in a stupid unix tool mishap with a command line that was one letter off from what it should have been).

        Watching hg and git grow up and compete as a darcs user was fascinating. Neither hg nor git had the elegance of the darcs UI (and arguably never will due to disparities in the underlying distributed code model), but it was clear from very early on that both hg and git were beating darcs on performance for large, active repositories. (Which was never a problem for a college student working on teams of maybe 1 to 3, but obviously a hard recommendation for the real world.) I experimented some with hg at the time because it had good Windows support, but had no reason to switch from darcs in college.

        My first couple of jobs after college had me spending a lot of time in TFVC, and that eventually that lead to a much greater appreciation of git (and pushing teams to migrate from TFVC to git), and by that point TFS had already starting supporting git side-by-side TFVC, though ironically those same teams pushed hard for GitHub Enterprise. (Which does seem to underscore that git and GitHub really were so co-beneficial.)

        By that point a lot of what hg had done right the git team was starting to pick up. At the very least, we should remember hg for pushing git to be better.

        (As one example, someone else pointed to `git stash` as something that they didn't think hg had, but as I recall `mercurial queues` [MQ] was one of the earliest hg plugins, and MQ influenced the designs of both `git rebase` and `git stash`, and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ.)

        • BeetleB 5 years ago

          >and MQ itself was mostly deprecated by `hg rebase` and `hg shelve` which learned a lot from MQ.

          I believe those have been deprecated in favor of the evolve extension.

          Mercurial is my goto for version control. However, in my experience, the information on the ideal tools/extensions is very scattered. The Mercurial book is 10 years old! For example, few mercurial users make use of branches for throwaway work - they use bookmarks. But how is a new user supposed to know that?

          • WorldMaker 5 years ago

            Neat. I was unaware of the evolve extension. It's interesting to see things continued to progress since I last read anything on the subject.

            All the documentation I spotted currently still lists evolve as "experimental", and that doesn't help with any confidence of which tools/extensions to use in day-to-day operations, on top of how scattered the documentation is. It is interesting, perhaps how hg has a better UI, but git has always had arguably more consistent documentation.

            (Similar too, both hg and git are built as sets of "plugins" to the core CLI but hg requires much more explicit installation and git just bundled a lot of them directly together and implicitly runs anything that even looks close [any script in the PATH that fits git-command may be run for git command], making it less clear which hg commands to use despite the better general UI, and easier to get started in git with a smorgasbord of commands.)

            I somewhat remember the Named Branches versus Bookmarks discussion/confusion thing from the last time I attempted to use hg. It sounds unfortunate that it still doesn't seem very well documented or well explained this many years later.

            • BeetleB 5 years ago

              >All the documentation I spotted currently still lists evolve as "experimental", and that doesn't help with any confidence of which tools/extensions to use in day-to-day operations

              I believe it is bug free, and fit for real world usage, and has been for years. If you read the details, the issue is there is a chance for performance degradation, and they consider that as "backward incompatible".

      • tasssko 5 years ago

        Git was successful before github. I’d say Github was successful because of git!

        • kjeetgill 5 years ago

          I was going to write this exact comment. I'm sure the "marketing" of "Linus Made!" and "used for the Kernel!" did git some favors, but git is technically superior in my experience, despite UI short comings.

          I'm sure it's changed now, but the lack of cheap fast branching was jarring.

          I think many UI fetishists forget: Good UI helps begginer adoption but has to be incredibly way better to drive any readoption. But professionals will often have to suck it up and use a shitty UI if it means solving a technical shortcoming better.

        • benibela 5 years ago

          And perhaps because there is no good offline ui for git

          So you end up using github as ui, even if you do not want to use a webpage

    • Grue3 5 years ago

      >I'll give hg the benefit of the doubt that it eventually got better

      It did not. We had a giant hg monorepo at Yandex, and even mere "hg id" took ages (and required net access to source repository for some reason). The plan was to eventually switch to it from SVN, not sure if they eventually did because I left the company.

    • jstewartmobile 5 years ago

      I've been using hg since 2012 on a few decent sized repositories, and it has never been anything other than immediate.

      • jschwartzi 5 years ago

        I've got a 1.2 GB repository and it's pretty fast for that once you set Watchman up to cache tree changes. It's dog slow without that little added step though, mostly because there are a ton of small files.

  • pron 5 years ago

    > So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use.

    Marketing is often necessary to get a start, but it is rarely sufficient for a long-lasting success. The claim that "it's all marketing" is usually made by those who look at one aspect of the technical merits and miss others that turn out to be more important. Just as in the actual VHS vs. Betamax story [1]. Betamax had a slightly, almost imperceptibly better picture quality, while VHS had double the recording time of Betamax. VHS won on the technical merits as they mattered to users.

    [1]: https://en.wikipedia.org/wiki/Videotape_format_war

  • zzzeek 5 years ago

    > So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use.

    this is an amazing opinion. Git won over mercurial because its capabilities and usage model are vastly better than that of mercurial. I had all of my projects on mercurial for many years and finally switched over to git, it was like a whole new world opened up. My daily workflows are now entirely based on concepts that are complete anathema to mercurial, where changesets are just objects that can be moved around or deleted once no longer needed, where commits to master represent complete features in a single changeset. Throwaway or hypotehtical branches are now changesets in Gerrit, rather than "feature branches" that exist forever whether or not they were used. I'm not sure if mercurial found a way to work out those problems of having zillions of little "fix typo" style commits crowding up a feature as well as zillions of dead feature branches forever crowding up the repo, but it at least was not apparent to me seven or eight years ago which would mean it's not easy to use.

    • Blackthorn 5 years ago

      It does: change evolution. It's very good.

  • gwbas1c 5 years ago

    > So a lesson in Software development is similar to betamax and VHS, so marketing is still a winner over technically superior architecture and ease of use

    The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better.

    In the case of VHS vs Betamax, VHS won because it was better overall. Some people point to one or two advantages of the Betamax format, but ignore that overall it wasn't better than VHS. (Because Beta tapes were physically smaller, you were usually forced to use a slower tape speed, loosing the very minor picture quality improvement at the highest tape speed. Thus, longer prerecorded Beta movies looked worse then their VHS versions.)

    The same thing is also the case with git versus Hg. I used Hg years ago because it was easier to learn; but once I learned git, I see no reason to go back to Hg. Yes, Hg has an easier learning curve, but that's one particular detail.

    • bch 5 years ago

      > The real lesson is that once a technology looses, the people who invested in the looser will run around forever calling the looser better.

      I can’t speak for all “the people”, but I disagree strongly. There are fine reasons for picking things other than git (I’ve used fossil since it’s near-inception); git’s dominance or fossil’s loss in the market does not make gits UI/UX superior. Thats like saying McDonalds is the height of cuisine, because “Billions and Billions Served”.

      • rumanator 5 years ago

        > Thats like saying McDonalds is the height of cuisine, because “Billions and Billions Served”.

        Actually, it's like saying that those billions are comprised of a hefty number of people who tried both and the vast majority determined that overall git is an unquestionably superior tool due to a combination of the tool itself and it's ecosystem.

        • bch 5 years ago

          OP> The real lesson is that once a technology [loses], the people who invested in the [loser] will run around forever calling the [loser] better.

          rumanator> [...] those billions are comprised of a hefty number of people who tried both and the vast majority determined that overall git is an unquestionably superior tool

          The majority doesn’t determine every persons taste. Git is the dominant DSCM; it’s well represented. Why be so defensive if some minority likes hg semantics?

    • woogley 5 years ago

      I'm sorry to be pedantic but you've used "loose" incorrectly 3 times in a row. It's "loses" and "loser"

      • ryandrake 5 years ago

        Not pedantic. English may not be OP’s native language, so tips like yours can be helpful. I found the rest of the comment to be insightful and true!

        • gwbas1c 5 years ago

          100% native English speaker... And 100% dependent on modern spellcheckers.

    • randomsearch 5 years ago

      “One particular detail” is a gigantic understatement. Having introduced several people to git, it is uniformly awful as a tool to learn, and that bad design doesn’t go away once you memorise the basics.

      • jschwartzi 5 years ago

        Yeah, my experience fits. I spent about 6 months at my first job trying to understand and use Git with AOSP. In contrast, my second job used Mercurial and I learned how to do everything Git could do in about 2 weeks, then never looked back. I always groan when someone has to use Git.

        I think people tolerate Git because they really like Github.

        • kjeetgill 5 years ago

          > I think people tolerate Git because they really like Github.

          I mean, I'll add to the pile of anecdotes this thread is accumulating but I don't know if it'll convince you that people are genuine:

          I struggled to learn git, but it was also my first VCS. I've needed to muck with hg a few times and vastly prefer git. Hg was fine. It didn't win my heart or anything. But it also didn't let me (at the time) branch as quickly and trivially and it was slow as hell.

          Sure, that need/want may not win a hg user to git, but I'd hardly call that tolerating git.

  • api 5 years ago

    Git won because it's superior in a way that many programmers think doesn't matter: performance.

    Git is incredibly fast. Many operations happen almost instantaneously even on large repositories. It's really nice. I've heard a lot of people talk about how they abandoned mercurial because it's slow. Some even switched to git from svn not because git's model is better but because svn is slower.

    "Premature optimization is the root of all evil" is an old programming advice quote that is so horribly misunderstood that it's basically wrong. It means think about your problem at the high (algorithm and overall goal / design space) level before worrying about low-level optimizations. It does not mean that optimization is bad or that performance isn't important.

    I made another comment recently on the same issue. I really wish that quote would die in favor of more substantial advice that won't be so misunderstood.

    • Noumenon72 5 years ago

      Are you working on a Linux system? I have the opposite experience with Sourcetree and Gitkraken on Windows -- git is the least responsive tool I use.

      • flukus 5 years ago

        Git is the only fast tool in that stack, it's slow because of the trinity of ntfs, electron and c# that those tools are built with. When you've got slow tools on a slow file system you're going to have a slow time.

    • benibela 5 years ago

      If performance mattered, people would not have adapted electron

    • benc666 5 years ago

      "Premature optimization is the root of all evil" means: make it work correctly first, and then - if anybody cares - make it fast. Readability/maintainability, then only as needed trade it off for speed, because not all code needs to be highly performant.

      • api 5 years ago

        Mercurial works correctly but is unbelievably slow compared to git.

        If you don't think about performance ahead of time (preferably at the algorithm level) then you will build something correct but slow and it'll be very hard to make it fast without redesigning major parts of it. It's possible to make design choices that paint you into a performance corner very easily, especially with something designed to work on a lot of data. O(n^2) might look like O(log n) for small data and in testing.

      • Shorel 5 years ago

        From the Knuth paper:

        "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

        It means make it fast in the code that matters, do not try to make it fast in every single line.

        To say the quote is often misunderstood is the biggest understatement in modern computer science.

    • marcosdumay 5 years ago

      I think any good advice in software development will be widely misunderstood. At lest, I haven't seen any that wasn't.

  • chuckdries 5 years ago

    I don't agree with the assessment that betamax was superior. Sure it had more advanced technology, but it was too expensive and much more complicated - it fit the business requirements of a home video system poorly

    https://www.youtube.com/watch?v=ddYZITaxlTQ

  • busterarm 5 years ago

    Unlike the VHS vs betamax comparison, Mercurial was not strictly-better than Git. Mercurial is quite slow in comparison and becomes brutally painful to wait for once your repo gets reasonably large.

  • neandrake 5 years ago

    There's also Phabricator as a self-hosted (and open source) solution for Mercurial (and Git and SVN) repositories.

    https://phacility.com/

  • chrisseaton 5 years ago

    > technically better architecture and user interface

    Maybe these things have not proved true in the long term? I think Git turned out to have the better UI and architecture.

    • bch 5 years ago

      > I think Git turned out to have the better UI [...]

      I think I have never heard that from anybody versed in git and any other distributed source control manager. Architecturally, we can look at (eg) speed performance and reasonable people could agree git leads or is a competitive contender. What UI examples is git bringing though?

      I’d love to love it, but to me it feels like a UI/UX disaster, and “getting used to it” is NOT an excuse when we have mercurial or fossil showing how much better it can be.

      • chrisseaton 5 years ago

        Things like interactive rebase in Git are revision control UI innovations with a massive impact on my ability to deliver quality PRs.

        Git feels like a tool I can use to create and mould meaningful commits that best convey intent. Mercurial feels like it wants to just make a literal log of what I've done, which is a bit simplistic and isn't the same as what I want to present when my code is ready.

        I also find the model of Git much easier to understand and explain to others.

        • pseudalopex 5 years ago

          Mercurial copied interactive rebase from Git a long time ago and refined it with phases[1].

          What do you find easier to understand and explain about Git's model?

          [1] https://www.mercurial-scm.org/wiki/Phases

          • chrisseaton 5 years ago

            Yeah they copied it. They copied it because it was better. Do you think that they copied it because it was a bad UI idea? Not sure what your point is.

            And great question about the Git model, after mentioning 'phases'! Mercurial has about a billion concepts and nouns for different random things like that. It takes forever to explain all the random ideas they've piled into it in an attempt to keep up with Git.

            Mercurial think they can fix everything with yet another plugin and new concepts and nouns. Git built a cleaner model where you don’t need these plugins and abstractions.

            • pseudalopex 5 years ago

              How does Mercurial feel like "it wants to just make a literal log of what I've done"? It has a UI very similar to Git's for rewriting history and a feature specifically to help do it safely.

              Git copied things from Mercurial too. I don't think Git having a feature Mercurial didn't in 2007 means "Git turned out to have the better UI and architecture".

              Git still has the problem Mercurial phases address.

              A lot of Git users are annoyed that Mercurial branches work like other systems instead of Git and that it calls Git branches "bookmarks". New users understand Mercurial branches much more easily in my experience.

              Mercurial queues are complex but only needed for workflows Git doesn't support. They're an extension so that most people don't even need to know they exist.

              Do you have any other examples?

              • chrisseaton 5 years ago

                > How does Mercurial feel like "it wants to just make a literal log of what I've done"?

                Because rebasing was literally an afterthought - a plugin. I don't think I ever push commits without rebasing them a few times. There's also now about six different ways to rewrite your history in Mercurial. It's a mess. Git has one way to do it and it's a normal part of the system.

                If a Mercurial user asks me how to tidy up their history my answer is 'er... well there's rebase, mq, histedit, evolve...' that's a lot of options to teach people. In Git I just show them rebase.

                It's all subjective isn't it? For me, less concepts, nouns, and plugins adds up to a simpler and so better architecture and UI. Maybe the extra concepts are what floats your boat and that's fine.

                • ygra 5 years ago

                  > Because rebasing was literally an afterthought - a plugin

                  Hg extensions are just as much part of hg as the core functionality. It's just that they're opt-in parts many users don't need and thus don't have to see. If your workflow requires history editing, then fine, enable rebase and histedit.

                  As for mq, I think I've only used it in a script where I converted an ancient CVS repo and rewrote entire parts of the history to remove stuff that should never have been in there to begin with. It's powerful, but rarely required by anyone, and thus is opt-in as well.

      • amluto 5 years ago

        I like git’s architecture better — hg’s exposure of revision numbers needlessly tangles branches together and makes anything that creates throwaway commits messy.

        But git’s user experience is IMO gratuitously awful. Trying to keep track of all the various things that checkout and reset do leads mainly to frustration at the design. And I see no reason that use of the index should ever be required.

        • WorldMaker 5 years ago

          Good news, in the latest git release checkout has two new friends that split checkout's functionality: switch and restore. Plus, they have much friendlier flags for knowing if they are affecting the index, the working tree, or both.

  • hylaride 5 years ago

    As somebody that spent a lot of time trying to convince people that BSD was superior to linux and eventually having to give in when linux won due to various other reasons I know how mercurial fans can feel.

    I still almost choke on my own vomit whenever I have to do any networking in linux that's more complicated that setting an IP address.

    • dragonsh 5 years ago

      I like mercurial not because I am fan, but pragmatic and my team can work well with it. I still use it on daily basis. Indeed my team use hg-git and also git to work with GitHub for synchronizing some upstream repository of libraries we are using.

      Also you bring a topic of BSD, I used it since 1993 along with Linux and still use both of them. These days I don't use Solaris and other Unix though.

      In early years used various flavors of Unix like IRIX, AIX, HP-UX, Tru64 Unix and settled on BSD and Linux.

  • hyperpallium 5 years ago

    Linus (and linux) was the key marketing; github and MS followed.

    Again due to linus/linux community, git has amazing polish (efficiency, error messages, docs) of a superb data model and brepus user interface.

  • kyrra 5 years ago

    Google contributes to Mercurial as well.

  • oaiey 5 years ago

    Just that git (w/o the central hosting/PR concept/issues) is the total opposite than proprietary, and despite the popularity of the social network GitHub (because that what it is) the market for hosting git repos is very active. Look at Gitlab, Bitbucket, Azure Repos, AWS, ... which are all just fine.

    I agree however with the fact that it is a pity to rely on a single tech which is not even the best of breed.

    • strenholme 5 years ago

      Another way to host Git code using 100% FOSS software is with https://sourcehut.org/ and of course it’s possible to host your own GitLab community edition server as per https://about.gitlab.com/install/

      • yjftsjthsd-h 5 years ago

        Sourcehut supports mercurial, too!

        • e_proxus 5 years ago

          The UI is a hot mess though. Every time I try out their Mercurial site (it's actually a separate site, not just a feature of the main site) I always somehow end up on the Git part of the site and there's no obvious way back.

  • philpem 5 years ago

    Another happy user of Kallithea here!

    I used to run Rhodecode some years ago, and switched to Kal when they forked. At this point I wouldn't be without it.

    • wuboo 5 years ago

      Kallithea was an option 2 years ago, now the development of it is basically dead. Rhodecode is still releasing regularly. Just check the feature differences: https://rhodecode.com/blog/133/rhodecode-vs-kallithea-compar...

      • dragonsh 5 years ago

        Who says development is dead. Please check the changelog.

        https://kallithea-scm.org/repos/kallithea/changelog

        Now lets look at Rhodecode. https://code.rhodecode.com/rhodecode-enterprise-ce

        You will notice that Kallithea has been consistently updated regularly. Besides user like me its also used internally at Unity Engine.

        Also the features you mentioned not all are in Rhodecode open source edition.

        • wuboo 5 years ago

          I'm not really following the "commits" but rather following releases. In the last 2 Years Kallithea had only 1 minor release (https://pypi.org/project/Kallithea/#history) 0.3 -> 0.4 without many new features. RhodeCode had 5 minor releases (https://docs.rhodecode.com/RhodeCode-Enterprise/release-note...) and multiple bugfix releases. I'm aware not all features in comparison are free, but we use the CE free version and it's enough for us at this point.

          • dragonsh 5 years ago

            Actually 0.3 to 0.4.1 is a major release with many changes including new mercurial versions and better git support with updated UI and celery for background tasks. If you see a new ssh feature is just added with documentation.

            Kallithea is pretty easy to work with and extend. We recently updated and built a CI using buildbot. Rhodecode and Kallithea have diverged enough and are moving differently. Also its a Software freedom conservancy project so it will be supported, hopefully it can attract bit larger community.

        • marcinkuzminski 5 years ago

          On a side note on this. I think Unity had their own fork of Kallithea with some changes that aren't in the official version ? Or those features are backported later from the Unity release

          • dragonsh 5 years ago

            I believe some of the unity developers are constantly creating pull request to update Kallithea and are core developers.

            Can't say for sure but I think Unity's system Ono is using Kallithea as core with additional plugins developed for their own use.

  • wuboo 5 years ago

    As you said it's sad but fortunately we have Rhodecode. In my previous company I was using Rhodecode plus mercurial and for developer working with it was a pleasure. Now in current company we using Bitbucket, we'll think then to moving to rhodecode because we still want to use Mercurial

  • strenholme 5 years ago

    “a single proprietary solution Github by Microsoft”

    Moving (Edit: Just the code, not issues and not pull request information) away from GitHub is trivial, since Git itself is open source and distributed, requiring merely setting up a repo on the new server (such as the open source Sourcehut) then running these commands:

        git clone https://github.com/foo/bar
        vi bar/.git/config # Add new remote location
        cd bar
        git push baz master
    
    (Replace foo, bar, and baz with real names)
    • atombender 5 years ago

      One-liner to change the URL of the upstream repo:

          git remote set-url origin <new URL>
    • Shorel 5 years ago

          # Add new remote location
          cd bar
          git remote add neworigin https://newserver.com/foo/bar
          git push --set-upstream neworigin master
    • ChrisSD 5 years ago

      And what about the issue tracker? Issues and discussions of pull requests would be lost by merely moving the code.

      • strenholme 5 years ago

        Some thing would be lost, yes [1] but the core code and commit history would be preserved. Issues can still be re-opened if still relevant, and pull requests can still be seen in the commit history. Comments on pull requests, if not approving a pull, will result in additional commits to the code which will be preserved.

        Whether this is OK for a given use case depends on how important ticket and pull request comment history is. For open source projects, I don’t consider that kind of history nearly as important as the code itself, since a lot of issues are wishlist requests, support requests, or downright spam.

        [1] Including branches unless one runs a script to go to and clone each branch to the new repo

  • jimmaswell 5 years ago

    I've been using Mercurial and git for a long time and I have to say git's workflow is a lot better. Mainly Mercurial doesn't let me pull or do other stuff with outstanding changes, for no apparent reason other than that the author wanted it that way.

    • pseudalopex 5 years ago

      Mercurial lets you pull and even update with outstanding changes.

      • silverbacknet 5 years ago

        This is one of my biggest pain points with hg vs git: Git is actually the one that flat-out prevents me from rebasing most of the time, usually for the most spurious of reasons, whereas hg just lets me choose to auto-rebase most files and pick the ones I'm interested in to manually merge.

      • marcosdumay 5 years ago

        And makes a mess of conflicts. I would rather not be able to do those things than to fix a conflict of a head with the working files on HG.

    • mixmastamyk 5 years ago

      > doesn't let me pull or do other stuff

      Not sure what that means?

      • jimmaswell 5 years ago

        It just doesn't let me do things with changes in the working copy sometimes where git does. It's really annoying.

  • ergo14 5 years ago

    I'm using RhodeCode, and so far it has been working great for both git and mercurial repo hosting - paired with Concourse CI it makes for a great combo.

  • benibela 5 years ago

    I still write my software in Pascal and store it an Mercurial repo on Sourceforge

    It was just the best development environment on windows

garganzol 5 years ago

It's funny to see how the whole world concentrates on this Git thing, while there is a treasure trove called Mercurial.

Mercurial was made for humans. It is seriously convenient and productive. Something I cannot say about Git, which more reminds me of an adhoc job.

I use both Git and Mercurial on daily basis. But my preference goes to Mercurial: it is just more sane in a big way. It is clearly a piece of art and love.

  • philpem 5 years ago

    The ease of use is a big thing for me. I find Git a bit arcane -- it's better than it used to be (around the Hg 0.9 era), but it's still quite bad.

    Hg has this way of actively pushing you towards the safe way of doing things (e.g. if you try to change history). Git will let you blow away a month's work if you mistype a command.

    I get the impression Git is the popular option because it underpins the Linux Kernel and Android development processes. That means it's popular, not that it's perfect for every use case.

    Mercurial is especially powerful when given to developers who know Subversion. A ~20% productivity boost just from being able to losslessly branch off and merge back without worrying about stepping on other devs' feed.

    Another team found out about it and were interested, but ultimately deployed Subversion -- because having one authoritative repository in one place was important to their process.

    • jlebar 5 years ago

      > Git will let you blow away a month's work if you mistype a command.

      It's sad to hear someone say that, presumably you've been bitten by it.

      What you describe is not true. While it's easy to blow away work you haven't committed, every commit you've made in the past month is saved in the reflog. Going back to any one of them is as easy as finding it and typing git reset --hard.

      Erasing something from the reflog is hard. Possible, but it's not going to happen by mistyping a command or two.

      Makes me sad because of course I agree the git UI is terrible, and I don't blame any user for not being able to figure it out. Although Googling "how do I recover lost git commit" does pull up useful results.

      • philpem 5 years ago

        I've lost a day's work to a mistyped "git revert HEAD~n"; my colleague blew away his month's work with a mistyped attempt at a squashed commit.

        Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try.

        Management asked "what if you do that with Mercurial?"

        Answer is, well, it won't let you do it without installing an extension. And the Wiki page for that extension contains a bunch of warnings about how you really should think long and hard about what you're trying to achieve -- and make as many backups as you can.

        TRWTF of course is that my colleague hadn't pushed upstream for a month. Like I said -- former Subversion user. He didn't want his commit to mean someone else had to do a merge, and he didn't want anyone to see it until it was done.

        • phaemon 5 years ago

          > Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try.

          Was "asking someone who knows how git works" on your list of things to try?

          What about "learning how git works"? Was that on your list?

          Frankly, you don't seem to have been trying very hard to get this work back.

          • jlebar 5 years ago

            > Was "asking someone who knows how git works" on your list of things to try?

            If I can make an analogy.

            There's little love lost on HN for C++. Anytime people mention C++ (possibly even here in this thread) people come out of the woodwork to talk about how hard it is to use, how it has too many features, blah blah.

            I work in C++ every day. I don't think it's that hard.

            When I have a question, I walk over and ask Chandler Carruth and Richard Smith. They are happy to help me debug my templates. Richard is the editor of the C++ spec, and Chandler is a well-known speaker, look him up on YouTube.

            Over lunch we talk about new features of C++, we rant and gripe, and I learn.

            Most people do not have Chandler and Richard in their life. Knowing them and the other experts on my team is a huge privilege. So when someone complains that C++ is too hard (wait for it, someone is going to do it here in this very thread...), it would be pretty insensitive of me to tell them that they should just ask someone who knows how C++ works.

            Most of us in this thread do have someone in our life who is good at git, who helped us get started, and who saved our asses when we initially got stuck. Maybe that person isn't with us IRL, maybe that person is "just" a message board or IRC channel where we know we're welcome. But this too is a privilege.

            If you've ever had trouble with anything and not had someone you could ask -- be it with C++, or real analysis, or whatever -- then I'd say you shouldn't throw stones at someone whose "whatever" happens to be git.

            • phaemon 5 years ago

              Ok, then I'll give you an analogy in return:

              Someone posts that they'd tried to join two strings in C++ and print the result. And they couldn't figure out how to do it; they would keep losing the second string. So, they gave up and changed languages, losing a month's worth of work.

              Would you think that was reasonable, because they didn't have Chandler Carruth and Richard Smith available to help?

              • jlebar 5 years ago

                > Would you think that was reasonable

                The thing I object to is judging them at all.

                They're not my coworker, someone I have to rely on and therefore might be annoyed if they're unproductive or whatever. They're a random person on the Internet who rather humbly admitted to making a mistake out of ignorance.

            • dreamcompiler 5 years ago

              Completely agree. Furthermore, I'm able to keep C and Common Lisp and most of Javascript and a bunch of other languages and Mercurial in my head (brain cache) so I rarely have to ask somebody how to use them.

              But try as I might, I cannot do so with C++ and git. They just make no logical sense to me.

          • tom_ 5 years ago

            To be frank, your sales technique needs work.

            • phaemon 5 years ago

              To be frank, I've no interest in selling anything so don't need a sales technique. To be franker, I think the OP was talking crap. No-one loses a month of work and doesn't think to get advice on how to fix it. It's just a stupid "git is bad" story.

          • nerdponx 5 years ago

            That's not the point, the point is that Git is a really bad interface to a really powerful system.

            • ozim 5 years ago

              Have you tried to operate an excavator? That thing is complicated compared to a car... But you know what? That is specialist tool. If you cannot operate with specialist tools you should not get a job of a specialist.

              I just had to write that rant out: https://wordpress.com/post/squarebits.wordpress.com/76

              • dreamcompiler 5 years ago

                I'm quite adept at driving an excavator. I can pour wine out of the bucket of an excavator. It's quite easy with practice because muscle memory kicks in.

                But if excavators were as hard to use as git, I'd never have mastered them.

              • creatornator 5 years ago

                I wouldn't say "programmers who use version control" are a group of people who would qualify as "specialists". Especially since all programmers should be using version control. It should be a fundamental skill necessary to entering the field.

          • philpem 5 years ago

            This was years ago, when Git was relatively new (around the time Mercurial was at v0.8-0.9).

            Our "Git expert" was the one who blew away a month of work.

        • minitech 5 years ago

          > I've lost a day's work to a mistyped "git revert HEAD~n"

          Mistyped as "git reset --hard HEAD~n"? git-revert is usually pretty nondestructive…

        • ozim 5 years ago

          Fuck that guy. Seriously if someone is in silo mode for a month I am going to fire that guy.

          He is doing either some dangerous changes, which is not acceptable OR he is doing something that could be walled off by feature switch and integrated with at least weekly commits.

          If it was some manager that told him to do that, fire that manager too!

        • dajohnson89 5 years ago

          You know that you can revert a revert, right?

        • dmortin 5 years ago

          > I've lost a day's work to a mistyped "git revert HEAD~n"; my colleague blew away his month's work with a mistyped attempt at a squashed commit.

          Don't you have backups? The companies I worked for had backups for all the home directories, so if I deleted something I could ask the admins to restore it.

          If there are no central backups I would sure as hell set up a local backup, so there are more than one copies of my work in case something goes bad.

        • nemetroid 5 years ago

          > Neither of us knew about Reflog at the time, so that didn't even get onto the list of things to try.

          ...so you thought you lost a day's or a month's work, you didn't actually lose it.

          • philpem 5 years ago

            No, we lost it after he tried to "fix" it when the commits disappeared...

        • favadi 5 years ago

          > git revert HEAD~n

          You could just revert your revert commit, or check out an earlier revision.

      • KaoruAoiShiho 5 years ago

        > While it's easy to blow away work you haven't committed

        This is bad enough. Git treats your workspace as trivial that can be replaced willy nilly.

        • jlebar 5 years ago

          I don't believe hg is any better in this respect.

          • yjftsjthsd-h 5 years ago

            I can tell you that it is in at least one use case that I've hit. If you have local uncommitted changes to a file, and then run `hg revert file` to undo your changes, it creates (by default) a ".orig" backup. The equivalent git command (`git checkout --hard` or something?) will just throw out local changes with no takebacks.

            • philpem 5 years ago

              I would absolutely love it if Git had this feature. Having it on Hg has saved me so many times.

      • dreamcompiler 5 years ago

        > every commit you've made in the past month is saved in the reflog

        I've heard this before. But since I seem completely unable to remember what a "reflog" is or how to use it, I always just copy my entire repo to another part of my disk before I do anything dicey with git (like rebase). This is of course ridiculous, but for me it's an easier workflow than "oh shit, I screwed up. Now I have to spend 2 hours on Google and SO trying to figure out how to get it all back."

        • bschwindHN 5 years ago

          Just in the case you didn't know, you can view the reflog with `git reflog`

          From there you can grab the commit SHA1s and view their changes with `git show ${SHA1}`, cherry-pick them to your working branch, or whatever else you want to do to recover them.

    • umvi 5 years ago

      > Git will let you blow away a month's work if you mistype a command.

      No, it won't. It's much harder to lose work in Git than you think. But really, if your remote repository is setup correctly with protected branches, this should never happen.

      • philpem 5 years ago

        I've never worked at a company with protected branches... even though it's best-practice. "Because some day someone might need to push to master to do a hotfix".

        So I have a local git push hook which blocks master pushes :)

    • airstrike 5 years ago

      > Git will let you blow away a month's work if you mistype a command.

      Fortunately, that can always be undone with another command

      • jhasse 5 years ago

        How to undo

            git checkout .
        
        ?
        • Rusky 5 years ago

          The only way for `git checkout .` to blow away an entire month of work is if you didn't add or commit anything for an entire month.

          • jhasse 5 years ago

            Fair enough ;)

        • airstrike 5 years ago

          That's like asking how to undo `rm -rf`

          • nemetroid 5 years ago

            It really is. Sure, it is an issue that it's the same subcommand as you use for many other things (which is being worked on with git switch/restore), but there is no other context where you'd do `git checkout .` if it wasn't your direct intention to get rid of changes in your workspace.

          • jhasse 5 years ago

            Mercurial creates backup files though.

    • bschwindHN 5 years ago

      > Git will let you blow away a month's work if you mistype a command

      What's the command to mistype?

      • fnord123 5 years ago

        Maybe git push -f my-branch

        I can't imagine having a month of work on a local machine that hasn't been pushed anywhere so it has to be something about pushing.

    • facorreia 5 years ago

      One thing I love about git is how it makes it almost impossible to lose work once it's committed. That's why I commit early and often.

  • MikusR 5 years ago

    At least on Windows Mercurial doesn't support filenames written in various languages. Git does. So Mercurial was made for one billion people while git for the rest 6.5 billion of us.

    • ptx 5 years ago

      What does "written in various languages" mean? Mixing multiple legacy encodings in one filename? Unicode filenames work fine on Linux (I just tested it with Chinese) and I would be very surprised if they didn't on Windows.

      • ChrisSD 5 years ago

        The problem, as I understand it, was filenames were read and written as bytes. That's fine if everybody is on the same platform but it doesn't always work when moving between, for example, Linux (UTF-8) and Windows (UTF-16).

        I don't know if that's still an issue.

        • ptx 5 years ago

          Hm, the Mercurial wiki does mention that's it was/is a problem on Windows.

          I was surprised because we've been using it for years at work, sharing repositories between Linux and Windows, and we have never been bitten by this. Maybe the latin-1 subset of Unicode works? Or all the files we worked on just happened to have ASCII names (despite us being mostly non-Americans).

        • chronial 5 years ago

          Unfortunately, on Linux, filenames are actually bytes, not utf-8.

          • ChrisSD 5 years ago

            Well yes and on Windows they are a sequence of 16bit values, not utf-16. My point was the encoding of filenames differ. So you can't do a byte-for-byte copy and expect the same results across platforms.

            As an aside, it'd be perfectly legitimate for Mercurial (and git) to reject filenames that aren't representable in unicode.

      • MikusR 5 years ago

        Various languages mean letters other than ASCII. They don't on Windows.

  • ChrisSD 5 years ago

    And yet people overwhelmingly chose Git. Why is that?

    • flohofwoe 5 years ago

      IMHO: Because Github just came at the right time for a free "no strings attached" project hosting solution when Sourceforge decided to become evil. That was the reason why I switched to Github anyway.

      That Github used this strange version control system cobbled together by the Linux kernel devs for their specific workflow was a bit weird, but that wasn't a showstopper for moving to Github.

      After all it was just one amongst many version control systems, and a VCS shouldn't be the centre of the universe anyway, over time Github would probably offer different systems anyway after they become more popular.

      Nobody expected that Github was essentially a Trojan horse ;)

      • kasey_junk 5 years ago

        It’s even more specific than that. GitHub chose “free public repos, paid private repos” as their business model and git as their DVC. Bitbucket chose the opposite.

        GitHubs model is incredibly more viral and thus git won (sadly IMO).

        • Siecje 5 years ago

          Bitbucket had free private repos and free public repos.

        • mixmastamyk 5 years ago

          Interesting, would like to hear more about why that is?

    • libria 5 years ago

      No clue. I thought for sure Mercurial would come out ahead, it had some proponents:

      * Bitbucket provided unlimited free private repositories and they were exclusively Mercurial. Github had limits for private repos.

      * Google evaluated both and preferred Mercurial for code.google.com http://www.saturngod.net/articles/dvcsanalysis-support-analy....

      * Fogcreek (creators of Trello and Stackoverflow) picked Mercurial to power Kiln

      Early on, both tools had different advantages but they evolved toward each other making the choice more about flavor and popularity. My guess is

      * git was strongly associated with Linus so it won that crowd handily

      * Github had a stronger association with open source than Bitbucket (dunno why though). Maybe it all came down to marketing. <-- there's a startup lesson

      • DougBTX 5 years ago

        > Github had a stronger association with open source than Bitbucket (dunno why though).

        Early on GitHub gave out free public repositories, but Bitbucket gave our free private repositories. Working in public is aligned much more closely with open source than working in private is.

      • billfruit 5 years ago

        As others have mentioned before, one possible reason could be performance, git commands work near instantaneously even for very large repos, perhaps mercurial was not able to offer a similar experience.

      • jhasse 5 years ago

        > * Github had a stronger association with open source than Bitbucket (dunno why though). Maybe it all came down to marketing. <-- there's a startup lesson

        Maybe because it was bought by Atlassian.

        • chipotle_coyote 5 years ago

          > Maybe because it was bought by Atlassian.

          Nope! Bitbucket had the "free private, paid public" model from the start. IIRC, Atlassian actually changed the model to allow unlimited public repositories after they purchased Bitbucket. It's possible that if BB had started with this model, they'd have been a much stronger competitor.

    • wokwokwok 5 years ago

      I used both at the same time at work for about 2 years, and mercurial was worse.

      Hg was slow, and the (custom) python plugins around it we used were frustrating (specifically, we had a build pipeline that used the mercurial module in python, along with an arcane scons thing) and there were some specifically irritating pain points like bookmarks and shelve that didn't seem to work properly.

      I mean, I get it, network effect... but all I can say is at least some people (like me) tried both and pick git on technical merit.

    • hiccuphippo 5 years ago

      Linus Torvalds made it. That at least got me to look into it. Then saw it was better than svn and never looked back. Or sideways, so I missed mercurial.

    • workthrowaway 5 years ago

      git was faster.

      i was using mercurial and svn before git. git was hard to learn but i went with efficiency and speed over convenience. also, if you have a good shell or a good GUI you don't need to memorize git commands. and if you are not a game developer uploading large binaries, git is the best around.

    • dtech 5 years ago

      At this point, network effect

    • tehlike 5 years ago

      Network effect and first mover advantage.

      • ChrisSD 5 years ago

        But they were both released at around the same time. Or at least near enough that they were both serious contenders for awhile.

        • gnud 5 years ago

          Mercurial was a bit slow in the first years.

          It's still probably slower for huge repos (I havn't checked), but I doubt it will bother you much nowadays.

          I used Hg before Git professionally, because when they were both new, Hg had _much_ better Windows support.

    • rimliu 5 years ago

      Many will not admit it, but git is just better. Back in 2008 I made a presentation about DSCVS where I introduced git, mercurial and bazaar, and my advice for fellow programmers was "use git".

mcbits 5 years ago

> June 1, 2020: ... all Mercurial repositories will be removed.

It's understandable that they would discontinue Mercurial support, but this part is shocking. No doubt that 1% includes more than a few obscure but historically interesting repos that will disappear because the owner wasn't monitoring their email (or is no longer with us).

Is BitBucket really that pressed for disk space? I hope they will reconsider and move those repos to a read-only archive like Google Code and CodePlex did instead of obliterating a piece of history for no good reason.

  • tosh 5 years ago

    This reminds me of patio11's analysis of tarsnap from a few years back: https://news.ycombinator.com/item?id=7523953

    "all Mercurial repositories will be removed"

    does indeed sound quite at odds with why people use Bitbucket. dissonance re core value-proposition.

    I hope Atlassian finds a less destructive way to phase out Mercurial support. Gladly they do have enough time to clarify / reconsider.

    • andrewshadura 5 years ago

      That's especially weird since serving Mercurial repositories in read only mode doesn't require any infrastructure apart from a static HTTP server.

  • flurdy 5 years ago

    Full bullet text:

    """

    * February 1, 2020: users will no longer be able to create new Mercurial repositories

    * June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed.

    """

    The February 2020 deadline to prevent creating new Mercurial repos seems too late. Why delay? Ok, not next week by why not 1st November 2019. You will just upset randoms that by accident creates a Hg repo with bitbucket only to be told it will be deleted soon.

    The June 1st 2020 deadline, is two parts. 1st part of disabling Hg features seems fine.

    But as you say the second part should be punted way into the future if not never.

    Sure, cripple it to read-only browsable only. But don't delete. There are plenty of tumbleweed open source projects that won't react before next year and be lost.

    • syntheticnature 5 years ago

      I don't think it's about disk space at all.

      Read only browse means nearly all the same code, with whatever vulnerabilities it has, is there and needs to be supported. I'm sure a good chunk of removing the all Mercurial support is not needing to keep an eye on the code to allow repo browsing, etc.

      • BlackFingolfin 5 years ago

        They don't need to allow browsing it; but at least have a minimal page which shows the presence of the repository, and allow cloning it.

        • guy98238710 5 years ago

          Or just provide a link to a tarball download.

        • tom_mellior 5 years ago

          Cloning it still runs code they don't want to run on their servers.

          • andrewshadura 5 years ago

            No. You just need a dumb webserver, no extra code needed.

  • dreamcompiler 5 years ago

    They could just convert them to Git repos automatically. If you do that manually, their press release implies that the repos will stay around. So it can't be a disk space issue. Why haven't they offered to do this rather than just remove them?

    • jobigoud 5 years ago

      According to the comments on the OP they tried to make a tool but couldn't make sure it would work in all cases for all repos, so they decided to not make a tool (and delete our repos instead). Such a disgrace.

      The funny thing is that github has an import tool. Since we are forced to move to the industry standard of DVCS, I guess many will use this opportunity to move to the industry standard of platforms as well. For my use case Bitbucket is now inferior or equal in all respects.

    • gmueckl 5 years ago

      The Mercurial data model is a superset of git's. A lossless conversion is simply not possible in that direction.

  • i386 5 years ago

    It’s very expensive to maintain two SCM implementations in something like Bitbucket and maintain feature parity between the two. Poor cost/benefit ratio.

    I remember back when I was at Atlassian and we had introduced Git repositories, Git usage grew an order of magnitude almost overnight.

    • jobigoud 5 years ago

      > we had introduced Git repositories, Git usage grew an order of magnitude almost overnight

      Not sure what you mean. There weren't any git repos before so yeah usage of git grew. Or do you mean global usage of git, including outside Bitbucket? I doubt it grew an order of magnitude.

throw0101a 5 years ago

They link to an SO survey:

* https://insights.stackoverflow.com/survey/2018#work-_-versio...

where "zip backups" and network copy (each 7.9%) and "no version control" (4.8%) are higher than Mercurial (3.6%).

If you're in that boat, I can understand not using git (87%) because its UI sucks (IMHO), and not using SVN (16%) because it needs infrastructure, but Mercurial has neither of those hindrances. Heck, even RCS would be better than nothing at that point, and Hg is better than that.

  • ilikehurdles 5 years ago

    Well git is the go-to default at many companies, so junior developers, if they learn anything, will learn git. People using network copy, no version control, or zip backups didn't choose those answers because they preferred them to mercurial; rather, they ended up with those because they either don't yet know about or understand how to use git (or any vcs).

  • doubleunplussed 5 years ago

    IMHO mercurial's usage is so low because github/gitlab don't support it. I understand bitbucket not wanting to, but it says nothing about what mercurial's usage would be like if people didn't have to choose between it and being able to use github or gitlab.

    • emilycook 5 years ago

      Hi GitLab employee. While we don't officially support it, there is a friendly fork project of GitLab CE that does, and we do provide official support to them :) https://heptapod.net/

ddevault 5 years ago

Sourcehut has Mercurial support. It's open source and community maintained, and will remain supported for as long as the Hg community wants it to be. We recently took our Hg team out to Paris to meet the Mercurial community at the first Hg conference, and discussed how we can get involved in the future of Mercurial and committed to continuing to improve our offering into the foreseeable future.

I've whipped together a script to help you migrate your repos to hg.sr.ht, for those interested:

https://hg.sr.ht/~sircmpwn/invertbucket

Let me know how it works out for you - I'd like to hear some test results before I post it to sr.ht-announce. Cheers :)

  • ntobjx 5 years ago

    One important feature is unfortunately missing: to also clone the wiki (which on Hg projects is a Hg repo in its own right). But that would probably pose a bigger problem, given that Sourcehut appears to have no feature like the (Gollum-based) Wikis in GitHub and GitLab (not sure what they were based on in Bitbucket, though).

  • bumbledraven 5 years ago

    Thanks for making `invertbucket`! I used it to import my bitbucket repositories and ran into a few issues:

    1. `invertbucket` should check that the machine has `hg` installed. (I accidentally ran it on a machine that didn't.)

    2. Say my sr.ht username is "thegreengiant" and my bitbucket repository is "abc". At the end of its run, `invertbucket` says:

    > Imported to: https://hg.sr.ht/srht_owner/abc

    That URL 404s. It would be an improvement if `invertbucket` replaced "srht_owner" with "~thegreengiant".

    • Sir_Cmpwn 5 years ago

      Thanks for the feedback! Fixed on both counts.

      • bumbledraven 5 years ago

        What sr.ht URL path would I use to get a page to render as markdown? hg.sr.ht/~thegreengiant/raw/default/foo.md renders as text.

        • Sir_Cmpwn 5 years ago

          Only the readme is rendered as markdown right now.

  • vnorilo 5 years ago

    Evaluating hg.sr.ht right now. On quick scan I saw that man.sr.ht has no API reference for hg - I was wondering what the status for that bit is. Thanks!

    • Sir_Cmpwn 5 years ago

      man.sr.ht has an API which is equivalent to git.sr.ht's API except for the portions which deal with querying git data:

      https://man.sr.ht/git.sr.ht/api.md

      So you can create and manage repos over the API today. We're still figuring out a good API design for fetching hg data over REST.

ryebit 5 years ago

Sigh. I really hate seeing hg languish like this. Command line is nicer, and I have yet to find any git gui frontend that matches what TortoiseHG can do (both in terms of invocating dialogs from the cmdline; and in terms of presenting and manipulating the graph).

I really hope something happens to help hg start accumulating more market share. Not just for my opinion on the tooling; but because IMO the "git = github = the only place for opensource" monoculture is kinda problematic.

  • McP 5 years ago

    The best TortoiseHg equivalent I've found (after a lot of searching) is SmartGit [1]. It's not as good as TortoiseHg and its not free but it's nice enough for most of my use cases.

    [1] https://www.syntevo.com/smartgit/

    • ntobjx 5 years ago

      Thanks for the pointer. I'll see if my company will "sponsor" me a copy. Looks nice indeed.

SpartanJ 5 years ago

I've been using Bitbucket with Mercurial repositories since 2011, both for private and public repos. I can count more than 50 mercurial repos that I'll need to manually move somewhere else. I'm really disappointed right now. I can understand their motives but they need to provide a single click method to at least convert a repo to git (this is a MUST IMHO).

I love mercurial but also can see that the community is shrinking, mercurial still relies on Python 2.7, and we are approaching to the EOL of Python 2.7. TortoiseHG also suffers from this, and the release cycle is always out of sync with the hg releases, and this breaks thg. These little things shows the sad state of mercurial, and in the end, this will drive most of the developers away from using it.

I guess it was great while it lasted... now, Bitbucket, please provide the developers the right tools to move away from mercurial with celerity.

  • doubleunplussed 5 years ago

    Hg already works with Python 3, and tortoisehg's Python 3 development is proceeding at a rapid pace. They're not dead, they just left it to the last minute, relatively speaking. I expect them both to make the cutoff of Python 2 EOL with stable releases.

    The releases being out of sync is not great, but if you're on Windows you download tortoisehg with a compatible hg, and if you're not your distro's repositories should ensure they don't push a new hg to you before tortoisehg is updated. I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks. Not a big deal. On Arch Linux since tortoisehg isn't in the repos it's a slight pain to hold back mercurial. Hopefully after the Python 3 transition tortoisehg makes it into the repos.

    ...though if there is not mercurial hosting available by the time bitbucket sunsets support, then maybe I won't care. I really want to keep using mercurial for my public open-source projects.

    • SpartanJ 5 years ago

      I didn't know that Hg already works with Python 3, that's great! The problem is that most distributions still will distribute the Python 2.7 version, I guess it makes sense until TortoiseHG catches up with Mercurial. I hope this happens soon, but I think that I'm going to switch to Git for the convenience of using GitHub over the other solutions (for open source projects the visibility is a good plus, for private projects I think GitLab is on par on features).

      > I went and looked at the history, and the average delay from a mercurial release to the corresponding tortoisehg is only about 3 weeks.

      3 weeks for me is a lot of time, that's at least 3 weeks I can't use TortoiseHg, something I use on a daily basis. Anyway, since this happened several times now I manually update hg and thg to avoid this problem (but it's a PITA). I know this is a problem with the distributor and not from the Hg or Thg devs, but still it's a common problem that could be coordinated between the two projects. I actually started using Mercurial because Thg was way better than the Git GUI tools at the moment, and I think this still applies.

      In conclusion, a hope the best for the Mercurial project but I'm afraid this will have a negative impact in the long term.

      • ntobjx 5 years ago

        Yep, wholeheartedly agree that it will have a bad impact. However, to me Git is nothing I would use voluntarily in my spare time as it is so hostile to its users (not to mention the conceptual shortcomings and outright questionable "features"). So for me it will be Mercurial and if that means helping out with Heptapod and/or other projects, so be it.

mamcx 5 years ago

This suck big time.

HG is by far the best UX of all SCM I have used. Without bitbucket I think usage of hg will drop even faster.

The sad thing is that git requiere so much arcane usage that hg have spared me for so much time.

I wonder why the worst always win? C, C++, JS, MySql.

Don't tell me is for "speed" or "features". Is incredible how much stupid effort and money go in put a lipsick on top of that when nicer ways exists... and are know... and have proved to work... and even faster (look at you, C/C++ build times)...

Even MORE bizarre is why not improve the tools coping what is good from others AND cleaning the usage of them?

Probably only python of the "good" side have critical mass...

  • umvi 5 years ago

    > The sad thing is that git requiere so much arcane usage that hg have spared me for so much time.

    Like what? I've been using git for 5 years and I hardly ever stray from the set {push, pull, reset, checkout, rebase}. I use VSCode for staging, committing, diffing, etc. though, so that probably spares me some commands, but I rarely (if ever?) have had to do what I would consider an "arcane" command.

    > Even MORE bizarre is why not improve the tools coping what is good from others AND cleaning the usage of them?

    Git has improved over time. Why, in the latest release they improved UX for the "checkout" command. Before it could mean "switch branch" or "restore file" but now there are 2 explicit commands: "git switch" (for switching branches) and "git restore" (for restoring files).

    • Siecje 5 years ago

      How do you create a new branch? Still git checkout -b?

      • umvi 5 years ago

        Under the new commands you would either do:

        `git branch <branch name> && git switch <branch name>`

        or

        `git switch -c <branch name>` (create and switch)

  • ntobjx 5 years ago

    The buzzwordiest always win because managers seem to rely on whatever comes up first in a web search. And that's typically Scrum, not Kanban. It's Git, not Mercurial.

    Managers won't have to work with the tools they impose on their subordinates. It's the subordinates who have to. But I have also noticed how a lot of people profess to "like" Git for spurious reasons like because it's (allegedly) "so powerful", but then they stick to the simplest workflow possible, because they don't have a clue about intermediate or advanced uses. But that same logic can seemingly also be applied to why C++ "won" (not that I dislike C++ as much as Git, though). The charm is in how powerful it seems to be, but then you use loads of third-party abstractions and throw the alleged performance benefits out of the window.

    For an SCM tool I want it to stay out of my way. It's meant to assist me in doing my main job. An SCM should not require my attention all the time because of the shitty CLI, inconsistent subcommands, horrible and incomplete documentation seeping with tool-specific terminology (see man gitglossary) and incomplete (or unidirectional) support for important features (git clone [here] [there], git push to remote with worktree).

    Git manages to always require ones attention, and typically in the worst way possible.

  • carapace 5 years ago

    I'd like git internals (merkle-tree etc.) with Mercurial's CLI UI, I think.

    • nemetroid 5 years ago

      It's quite possible to write your own Git CLI, the fundamentals are well exposed.

      • ntobjx 5 years ago

        It works until it doesn't. One of the biggest problems with Git IMO is that it always exposed a plethora of internals which therefore have become public interfaces. One is to be expected to know the guts of .git as an intermediate/advanced user. And because those are interfaces, it's _always_ going to be very difficult to fix issues arising from previous wrong design decisions.

        Fundamentals in Git aren't necessarily easy to use from the CLI, but you'll get by with a dozen or so command line invocations overall. And I found it astonishing and disheartening how so many people were able to make do with completely illogical commands like "git checkout -b" ...

        But once Git sticks you the finger and you _need_ to delve down into its guts, you often have a problem.

        Now don't get me wrong, the amount of GUI tools hiding Git's intricacies and web interfaces like GitHub glossing over numerous shortcomings of Git have certainly helped the UX and the popularity. But once you _have to_ delve down to CLI usage because you ran into an issue that your tool tries to gloss over, most people are at a loss. And most people will opt to scrap the current clone+worktree and clone anew. That doesn't really sound to me like people are in command of their tool of choice (Git), though.

        And at this point we haven't even touched stuff like refs which only differ in case. It's all fine until Git starts unpacking the refs. Which can be fun on systems like macOS and Windows which have support for case-sensitivity in the file system, but who opted to forgo that via a setting.

  • flukus 5 years ago

    > Don't tell me is for "speed" or "features"

    In this case it was speed. Git respected the time of it's users and hg respected the time of it's developers more, it's in no way surprising that users picked git.

    > The sad thing is that git requiere so much arcane usage that hg have spared me for so much time.

    IME the only people that struggle with git are people that refuse to learn it, properly learn it and not "pick it up as you go". It's such a small time investment that pays off for any professional.

vnorilo 5 years ago

I will be affected. I think I will take a serious look at sourcehut[1] now. I get a good vibe, but the bus factor scared me away before.

[1] https://hg.sr.ht/

  • Sir_Cmpwn 5 years ago

    Don't worry, in the event of my untimely demise there are trusted people with access to the servers to pick up the mantle.

    • vnorilo 5 years ago

      Sir, I wish you long life and godspeed, but my threat model includes acquihire and lost interest ;)

      However, I keep talking how we need to avoid monocultures, so I guess it is about time I assume some minor risk.

      • Sir_Cmpwn 5 years ago

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

        Sourcehut has accepted no external funding and once the alpha period ends, all accounts must be paid. Even with optional payment, it already turns a profit. I'm pretty confident in the sustainability of the service.

        As for me losing interest, the good news is that I need software hosting no matter what I'm working on, so I'll always be working on it. And, since it's open source and patches are welcome, so could you add anything you need.

    • bjoli 5 years ago

      You just got another paid user. I am very much in the amateur hacker camp, so I might not add much revenue. Anyway, thanks for sourcehut. Mercurial is my preferred way. I have managed to shoot myself in the foot so many times with git that I just gave up on it and since it is my hobby I don't want to spend much time with git.

pgt 5 years ago

It would be interesting to read a breakdown of why Mercurial failed against Git. It is superior to Git in every way except performance and adoption. Git won because GitHub won, and I bet GitHub chose Git over Hg's Python implementation because it was too slow.

I wonder if Mercurial would have won if it was implemented in C or Rust (had it existed then).

  • jlebar 5 years ago

    > It is superior to Git in every way except performance and adoption.

    Performance is such an important advantage, though.

    I type git diff hundreds of times a day, and when I switched from hg to git at Mozilla, this made such a big difference in my life.

    These days I type hg histedit maybe fifty times a day at Google, and I cry every time because it is so. glacially. slow. hg diff too. And I'm working with a relatively small repository.

    Speed matters for tools we use all the time.

    I'd also posit that the process of writing "plugins" for git is much easier than writing hg plugins. A git "plugin" is just a shell script that uses git. If you can use git, you can write a shell script that uses it. An hg plugin...whoaboy.

    • durin42 5 years ago

      Please feel encouraged to report a bug about histedit slowness with some details so we can try and reproduce and consider a fix.

      • jlebar 5 years ago

        I'll see what I can do. Because it's Google code, it may not be feasible. But we have a whole team of hg developers ourselves, maybe I should bug them before putting it on you. :)

        • mambru 5 years ago

          Including durin42 himself ;)

        • ezst 5 years ago

          well, you just addressed this message to the current lead maintainer of Mercurial, who happens to be a fellow co-worker of yours ;)

    • pgt 5 years ago

      Please correct me if I'm wrong, but I think it was in "The Hundred-Year Language" [^1] where @pg argued for performance as a language design feature. He could have meant a different kind of performance though.

      - [^1]: http://www.paulgraham.com/hundred.html

    • jwatt 5 years ago

      Have you aliased `hg` to `chg` (built-in I believe). That solved things for me.

      • jlebar 5 years ago

        I hadn't heard of this! It definitely helps with startup time.

            $ time hg help > /dev/null
        
            real 0m0.232s
            user 0m0.196s
            sys 0m0.033s
            $ time chg help > /dev/null
        
            real 0m0.081s
            user 0m0.003s
            sys 0m0.000s
        
        But because an empty `hg diff` takes 1.3s for me, taking 150ms off the top isn't a big help.

            $ time hg diff
        
            real 0m1.383s
            user 0m0.558s
            sys 0m0.333s
            $ time chg diff
        
            real 0m1.224s
            user 0m0.003s
            sys 0m0.007s
  • microtherion 5 years ago

    Part of git's success might be due to its initial association with Linus.

    Which I would find mildly ironic, because Linus initially was one of the last prominent holdouts against version control systems, and then made (in my opinion) a very ill-conceived decision to go with a commercial version control system that effectively made it harder for non-prominent, non-paying developers to contribute.

    So when he decided to build his own version control system, I'd say it was not a foregone conclusion that he was a particularly qualified expert in the field. But in retrospect, the technical architecture underlying git has held up well (the UI maybe not so much).

  • simias 5 years ago

    I'm reminded of that article I read on HN a few months ago about how "you're not Google/Amazon/Facebook" and you probably shouldn't base your technical choices on what these companies are doing because chances are that you have a massively different usage profile and very different priorities. Still, everybody wants to be like the big guys (dress for the job you want, not the one you have) so you still often seen small-ish websites using a ridiculously overpowered and over-architectured backend.

    I think there's a bit of that in Git vs. Mercurial. Git was built specifically for the Linux kernel and it shows. Most of its quicks and features make sense in that context. But the thing is, the overwhelming majority of projects out there are not anywhere similar to the kernel. They have fewer contributors, there are generally much more centralized, they don't use 90's style mailing lists, they don't deal with dozens of millions of lines of code etc...

    I think for that "silent majority" of projects Mercurial was a much better choice indeed. It's simpler, for a long time it was much better documented, it was also easier to migrate from SVN and other centralized version control systems. But Git was cooler, it's what the kernel used, and if it's good enough for the kernel then it's good enough for me!

    That being said at this point it's clear that Git has won. I've been slowly migrating my (active) projects to Git over the past couple of years. I'll have to use Git one way or the other anyway, I might as well try to uniformize my workflow. RIP Mercurial, you deserved better.

    • philpem 5 years ago

      There are similar patterns in other industries. Manufacturing tends to fetishise the automotive industry -- so an absolute mountain of changes come from "well Toyota's doing it" or "well BMW is doing it". Of course, they're great solutions for building cars, but not so great when you're building TV remote controls.

      I wouldn't say Git has "won" or Mercurial has "lost". Hg still sees a lot of active development from the maintainers. As do Subversion, Perforce, and so on. Heck, ClearCase is as old as the hills and even that still has an active user community.

    • juped 5 years ago

      Use everyone's favorite Sourcehut, which works with (not against) the mail-centric workflow of Git. (Or use Mercurial on Sourcehut.)

    • gilrain 5 years ago

      On the other hand, the software development version of the maxim "dress for the job you want, not the job you have" could easily be "use the tools the job you want uses, not just what you can get away with".

  • gpderetta 5 years ago

    > It is superior to Git in every way except performance and adoption.

    For me, and I suspect for a lot of developers, the single biggest advantage of git is that it is fast.

    • simias 5 years ago

      I'm not so sure really, in my experience the performance difference only becomes noticeable if you have a very large repository. For the Linux kernel I'm sure it matters, for "my library with 100 commits and 10k lines of code" it won't make a significant difference.

      • dbt00 5 years ago

        Most commercial projects are orders of magnitude more complex than that, and the performance differences are stark.

      • plorkyeran 5 years ago

        I have worked on many projects where I have wished that git was faster. It doesn't take a very big repository for performance to become an issue.

      • newen 5 years ago

        People are going to go for something that runs in 0.1 seconds as opposed to 1 second, most things being the same.

  • dragonsh 5 years ago

    Performance is not the reason GitHub chose git over mercurial. They chose git because their core developers understand internal architecture of git better. They were more proficient in Ruby and C than Python, so git was a natural choice for GitHub.

    Python language used mercurial for quite sometime to manage all it's repository, they moved to GitHub not for performance but for inertia of mass adoption, knowing very well that git has inferior user interface and they need to rely on GitHub to make it work for them. Facebook, Unity engine still use mercurial.

  • rimliu 5 years ago

    I have no idea how good mercurial is now, but I think back in the days when git started to get ahead it was superior to mercurial in more than one way.

  • rsynnott 5 years ago

    > except performance

    That's a big except. Mercurial was far too slow. Not sure if that's still the case; I haven't used it in years. But it was slow when the field was still open to competition.

  • nerdponx 5 years ago

    In my understanding it's the opposite, that Mercurial is effectively a subset of Git. But I was never a Hg user.

    • andrewshadura 5 years ago

      Well, you can express any Git repository in Mercurial terms, but not otherwise.

ldng 5 years ago

Over the year I've used CVS, SVN, bazaar, Mercurial and Git. Mercurial has always been the one I struggled the most with. It never clicked with me. Just to respond to some arguments I see floating around.

In my last team we switched from Hg to Git and absolutely everyone but the CTO felt more comfortable with it. including the data scientists.

To me, Mercurial UI might be friendlier than Git's but it's really a moot point if it does not fit with the way people actually think/work.

Also, I sincerely think Git was getting more popular _before_ Github. Granted, it massified the adoption.

twic 5 years ago

I and the dozens of other remaining Mercurial users will be severely inconvenienced by this.

Still, at least SourceForge still has Mercurial support!

  • riffraff 5 years ago

    Savannah allows using mercurial[0] and is likely less evil than sourceforge.

    [0] https://savannah.gnu.org/maintenance/WhyChooseSavannah/

    • twic 5 years ago

      > Savannah has high project approval requirements and thus visitors can expect freedom-related qualities from projects hosted here

      Is that code for "must be under GPL"? I'm a BSD man myself.

      • belorn 5 years ago

        https://savannah.gnu.org/register/requirements.php

        It does not explicitly give out a list on that page (to get that you need an account), but from a read it seems to say GPL-compatible which BSD is.

        The repository has a very explicit goal: The expressed purpose of advancing free software that can run in free operating systems. Licenses aside, the answer to the question if a project is suited for Savannah is likely answered by looking at that goal.

      • riffraff 5 years ago

        I honestly do not know. I believe I had a MIT licensed project there many years ago, but I would not surprised if it's GPL only.

  • mort96 5 years ago

    I wouldn't trust SourceForge at all after all the horrible stuff they've done. I know they have allegedly improved after new owners and a come-to-jesus moment, but damn, that was some shady shit.

    • srean 5 years ago

      I think you are thinking about the old and nasty sourceforge. They have since been bought and the new owners have changed what nasty old sourceforge used to be

      • mort96 5 years ago

        > I know they have allegedly improved after new owners and a come-to-jesus moment, but damn, that was some shady shit.

        If Facebook tomorrow started saying they're totally going to stop being creepy and got a new CEO, I wouldn't suddenly start trusting them either.

        • loganabbott 5 years ago

          We're a small independently owned private company, and not a single person responsible for those decisions made years ago is still involved with the company. It's been over 3 years since we bought SourceForge and we reversed all the bad decisions on day 1 and never looked back. We still support Mercurial https://sourceforge.net/p/forge/documentation/Mercurial/#pub...

          • mort96 5 years ago

            But why buy such a tarnished trademark which has garnered so much ill will over the years for horrible practices? Is it a form of "all PR is good PR", that it's better to have a recognized but hated name than to have a name nobody knows of?

            • loganabbott 5 years ago

              Most people have gotten the message that things have changed at SourceForge. We bought it to redeem the name and protect free open source software.

          • garaetjjte 5 years ago

            I still avoid SourceForge links because of that annoying 'Your download will start shortly...' interstitial.

    • jlebar 5 years ago

      I suspect the whole post was a bit tongue-in-cheek, not just the line about "There's dozens of us. Dozens!"

  • mouldysammich 5 years ago

    sr.ht also recently added support for hg

  • marcinkuzminski 5 years ago

    at RhodeCode we used to have a hosted Mercurial repositories service. Actually, it was a per-customer isolated instance that we hosted on digital ocean. We have all the logic and code still here, i wonder if we should bring that back to have people host their Mercurial repositories.

jzwinck 5 years ago

Doesn't this mean BitBucket will die? Slowly, sure, but Mercurial support seemed like a key differentiator relative to GitHub.

  • probably_wrong 5 years ago

    Mercurial support was the one reason for me to still use Bitbucket: there is no other Bitbucket feature I can think of that Github doesn't already have, while Github's community is miles ahead since everyone and their dog is already there.

    More importantly, Bitbucket leaves the migration to you (if I read the article correctly). Once I download my repo and convert it to git, why would I stay with the company that just made me go through an annoying (and often painful) process, when I can migrate to Github with the exact same command? And why isn't there a "migrate this repo to git" button right there?

    I want to believe that Bitbucket has smart people and that this choice is a good one. But I'm with you there - to me, this definitely looks like Bitbucket will die.

  • the_duke 5 years ago

    They wouldn't have done it if a they had a significant user base using Mercurial, or if Mercurial usage was showing promising growth.

    • cmiles74 5 years ago

      The article claims that virtually no new accounts are using Mercurial support at all.

      I suspect that they are working on improving their build pipeline and CI tooling and it's proving to expensive (perhaps in both time and money) to get that working reliably for both Git and Mercurial.

  • philpem 5 years ago

    The key differentiator on Github's side is community involvement. The UI allows you to quickly search for projects across repositories.

    Bitbucket seems more geared to teams working internally; finding projects on Bitbucket is hard.

    To be brutally honest, I used Bitbucket because I had a grandfathered academic account (most features free). Github offers nearly all that I had on that account now.

    Github is great for "social" coding, but Bitbucket is very clearly moving towards targeting insular, corporate development tasks. But then, with the price ticket on Atlassian's products, that's hardly a surprise. B2B is their bread and butter.

    • antupis 5 years ago

      yeah, I think that open source and other social products will gear towards Github. While Bitbucket will thrive in B2B space. currently, JIRA has a huge moat around it and I am not seeing that disappearing in the near future.

      • philpem 5 years ago

        There's already a self-hosted version of Bitbucket which is fairly decent aside from being as slow as molasses (which, let's face it, is an 'Atlassian thing' at this point).

        I used to use Jira extensively for my own internal projects (and, hilariously, my personal TODO list), but I'm moving away from that. I'm moving from my own personal server to a couple of Droplets, and I realised in moving JIRA across just how bloated it is. Most of the SCM integration tools I use are pay-for now, so for $10/yr, I'm getting less than I'd get with a Mantis or Bugzilla install.

        I need to have a look for a new bugtracker. Custom Workflow support would be nice, that's really the only feature which kept me on JIRA for so long!

  • DanHulton 5 years ago

    If it's going to die (and it might, I know I couldn't get off it fast enough), this can likely only help, not hinder.

    Not every feature helps you. There's a support burden with every line of code, and the support burden for another entire version control system is probably pretty high. Every new feature you add has to either be written for that second version control system as well, or come with a disappointing article explaining why not.

    If anything, this has the potential to free up resources they can spend on creating a differentiator that engages more than 1% of their customers.

  • krzyk 5 years ago

    It is quite funny because BitBucket started as a GitHub for Mercurial users (it had only Hg support).

    Then they (after it was sold) added git support and now they are removing hg.

  • x3n0ph3n3 5 years ago

    Unlikely. The deep integration between JIRA, BitBucket, and Bamboo is a huge selling point.

  • Sean1708 5 years ago

    As a data point, our company that only uses git moved from GitLab to BitBucket literally about two months ago. No idea why (waaaay to low on the food chain) but I'm guessing it must have some advantages at least.

    • vidanay 5 years ago

      Most likely you will also see a Jira roll-out soon (unless that preceded the move to BitBucket)

    • heavenlyblue 5 years ago

      We have moved from BitBucket after they had several days worth of unavailability over a year and the fact that they would regularly decline our company credit card, which would subsequently immediately block all commits to our repos.

      It was a mess which was simply fixable by re-submitting the card details again.

      They only had one job.

  • pard68 5 years ago

    We use Bitbucket at work because they offer selfhosting. Until Github can offer this I don't think Atlassian has anything to worry about.

barseghyanartur 5 years ago

This is terrible news.

I prefer Mercurial to Git. I intensively used both for years and I can't say that Git is any better than Mercurial.

I do think they should at least come up with a plan to seamlessly migrate existing repositories to Git. Still, shocking.

antonyme 5 years ago

What a damn shame. I use git when I have to, hg when I get to choose. The usability and ergonomics are just so much better. I've never had any performance complaints. I chose Bitbucket over Github specifically because of Mercurial support. Unfortunately it's a business decision and they had to make a tough call.

dylanz 5 years ago

I remember playing pool with Chris Wanstrath back in the day and he was telling me how he just started a product based on Git. I told him to bail on it and use Mercurial instead! I listed a bunch of reasons why I thought it was the best distributed VCS. I remember shaking my head a bit thinking: "Whelp... good luck with that". I probably lost that game of pool too.

dogweather 5 years ago

OMG, sad. And I'm part of the problem:

I've always wanted to use Mercurial; I'd always found its user interface to be an improvement over git; as if it shipped with a great "porcelain" by default. I respect its ability to leak fewer implementation details while still offering plenty of power.

But I kept using git for all my projects, and GitHub with it.

caiocaiocaio 5 years ago

I feel old. I can literally remember dozens of silver bullet technologies I was told were necessary to know ("you're not a real professional if you don't..."), and then forgotten by nearly everyone. All of these were supposed to save the world and most of these were cutting edge less than ten years ago.

gumby 5 years ago

I'm astonished, just because hg defined bitbucket for me. Else its other features were just OK.

Also, though I never found a reason to choose hg I had been told that it fit the Windows file system better than git. If so that wasn't enough.

burner6565 5 years ago

Since this is likely to attract bitbucket users, I’ll toss out a question in hope someone knows:

It appears that in bitbucket enterprise cloud, there is no way for me as an administrator to prevent members of my team from making repositories public to the Internet. Is that true? If so I may need to look to on prem options, or perhaps GitHub enterprise cloud which seems to support better permissions. We deal in sensitive data so can’t risk an analyst publishing them to the net accidentally.

_pmf_ 5 years ago

Strange. I would have thought that serving more niche customers would be a more sustainable business model than competing against GitHub and GitLab on their home turf.

Is Bitbucket profitable?

  • nixgeek 5 years ago

    It’s owned by Atlassian but who knows if revenue generated exceeds costs incurred for that specific product. Somehow doubt they’re going to disclose that.

    Would be nice if companies were transparent about which products and services made the most money, rather than (best case, public companies) stating earnings for the whole company and breaking it out fairly opaquely through categorizations.

    On the flipside I could see this being useful information to competitors, and instructive on which parts of your business to attack.

errnoh 5 years ago

The Software Heritage [1] was mentioned in another thread today. They seem to archive source code from most of the popular locations, but Bitbucket doesn't seem to be on the list?

If Bitbucket is planning on actually removing Mercurial repos it seems like a good idea to crawl and archive those before that happens.

[1] https://www.softwareheritage.org/archive/

thieving_magpie 5 years ago

I have 92 mercurial repositories at my company that I'll need to convert.

dreamcompiler 5 years ago

All my software is in Bitbucket for two reasons: Free private repos and Mercurial. Now that Github has free private repos and Atlassian is removing support for Mercurial, I have no remaining reason to keep my repos in Bitbucket. Sayonara, Bitbucket. You just created a Github customer.

wooptoo 5 years ago

When I picked up a DVCS years ago I initially went for Mercurial for its ease of use. It had a clean command line interface and it just clicked with me (Git still had some bits written in Perl). It worked very well for my small projects. Its hgweb worked without fuss on top of Apache (which was still popular). Bitbucket was a small time site back then (about 2008) and I mainly hosted the projects locally on a web server.

However the industry has voted by putting its weight behind Git and Git has won. It has caught up usability-wise. Its performance is miles ahead of Mercurial. While its underlying model is not straightforward to grok it enables great work flows.

Honestly I'm happy with Git and never looked back.

z3t4 5 years ago

Only reason I use Bitbucket is because of Mercurial. I guess that's what you get for using centralized services. The funny thing is that both Git and Mercurial was designed to be decentralized! But we humans are social creatures, and Github is like Facebook for invert's - instead of posting pictures of your acquaintance you post your software projects. Stars are the likes ... So in order to fully decentralize, the human/social bit also need to be decentralized. But there is also the convenience, while setting up Git and Mercurial hosted repositories is straightforward, I can understand why dev's choose to use a service instead, especially when it's free.

irishsultan 5 years ago

When clicking on the link to "A Community thread to discuss conversion tools, migration, tips, and offer troubleshooting help", I see:

Article not found

The article you are trying to access is not available.

It may have been deleted or marked as spam.

gitbucket 5 years ago

I am annoyed at this news. v1. Bitbucket == Mercurial v2. Bitbucket == Mercurial|git v3. Bitbucket == git However, GitHub is better at git, so now GitHub > Bitbucket

May bitbucket and it's management forever have it sheets and stocks shorted. They deserve it.

Since I want my repos' outsourced and I'm being forced to use git, I am moving to GitHub.

Define: git - https://www.google.com/search?q=what+is+a+git

DenisM 5 years ago

Guess I'm taking my money and going elsewhere, then.

Several things seem really odd to me:

  - They are ditching one thing that was a safe harbor from github.
  - No migration path to Git inside bb service. 
    If I am going to migrate outside bb I might as well move away completely.
  - Armageddon-style wholesale destruction of the old repos.
    Could have left the read-only repos on a separate server. Or even just a tarball.
It just looks so disorderly and thoughtless...
fredcy 5 years ago

Damn, this is disappointing. I've long preferred hg over git but developer preference has clearly moved to favor git. I like using mercurial queues for managing local config changes but I guess I'll have to get better using `git stash`. I hope bitbucket provides some tools to easily convert repos from hg to git. Frankly, though, I'll likely just move from bitbucket now.

cosmojg 5 years ago

For anyone looking to jump ship, check out invertbucket (https://hg.sr.ht/~sircmpwn/invertbucket), a script which automates the transfer of mercurial repos from Bitbucket to Sourcehut. Support for transferring tickets and pull requests should be coming soon as well.

bovermyer 5 years ago

A friend of mine is a core contributor to Mercurial. He is... well, I suppose "livid" is as close a descriptor as any.

scblock 5 years ago

Enjoy your monoculture.

hiccuphippo 5 years ago

Is there any feature in mercurial that git doesn't have? Is there some plugin to allow mercurial users keep using the client with a git remote repository (like the one for using git with svn)?

  • durin42 5 years ago

    1) hg absorb

    2) hg-git exists, and there's other things afoot that should be better

    • Mindless2112 5 years ago

      As a daily hg-git user, could you elaborate on (2)?

      • 1wd 5 years ago
        • benibela 5 years ago

          That would be helpful

          I use hg-git to put all my Mercurial based projects on Github.

          But the last OpenSUSE update installed Mercurial 5, but left the old hg-git for Mercurial 4. Now it does not work anymore.

          • 1wd 5 years ago

            On Windows it is broken since TortoiseHG 4.5.2

            • benibela 5 years ago

              TortoiseHG is really cool

              I used to use it all the time on linux.

              Unfortunately the OpenSUSE update also removed it. Completely, it is not even listed in the package management anymore.

              No one wants to maintain non-mainstream software

  • andrewshadura 5 years ago

    Changeset evolution for starters.

    • sterileopinions 5 years ago

      You mean the thing that was only suitable for real world use by in-the-wild development teams last year? Something no repo provider really fully supports even to this day?

      From HG's own documentation (https://www.mercurial-scm.org/wiki/ChangesetEvolution):

      >While well on the way, the full implementation of the changeset evolution concept is still in progress.

      HG's entire system requires far more investment in the tool than git will ever ask of you. And you probably don't need the feature in the first place. I consider changeset evolution a nifty feature, but it's also a devop smell in my book.

      • krupan 5 years ago

        Changeset evolution has had the "beta" label for way too long. I started using it years ago and it was fine.

        As far as smells go, its whole purpose is to make editing history less "smelly" than git's rebase -i followed by force push.

        • sterileopinions 5 years ago

          > I started using it years ago and it was fine.

          You are not a full blown development team, and beta software works for many people. That doesn't mean it's ready for prime time.

      • andrewshadura 5 years ago

        No. Evolution was usable since 2015 at least. Supported by Bitbucket and others.

        Evolution requires no effort whatsoever to maintain.

mixmastamyk 5 years ago

A disaster for me, I've got dozens of hg repos over there. Do they support an automated conversion? If not, probably no reason to use bitbucket any longer.

  • jobigoud 5 years ago

    I'm in the same boat. And Mercurial support was the key differentiator for me, I'll probably convert the repos to git (hg is almost sure to die after this) and move to GitHub in the process, including the git repos I have on Bitbucket.

Bellyache5 5 years ago

It seems that Bitbucket and GitHub are trying to emulate GitLab’s strategy of being a one-stop tool rather than just version control.

  • nathancahill 5 years ago

    The opposite is true actually, Bitbucket was bought by Atlassian in 2010 to make Atlassian the one-stop shop, a strategy GitHub and GitLab are emulating (GitLab launched in 2011).

    • dochtman 5 years ago

      Seems to me that one-stop shop is very different from one-stop tool. GitLab is aiming for the latter, whereas Atlassian (at least when I was using those tools) seems much less integrated.

      Jira may be the most comprehensive issue tracker (which isn't necessarily attractive -- but then they have Trello now, too), but on the version control and CI front I don't think Atlassian will have an easy time competing against Azure/GitHub/GitLab.

  • oaiey 5 years ago

    I think the ALM market was defined and alive before any of these companies even existed. It is natural evolvement of these companies.

    The common user just realized he or she needed more and demanded them for free.

    The Enterprise market had DevOps features long before DevOps as term existed.

srean 5 years ago

Anyone knows what happened to Spolky's hginit.com ? It used to be one of the most accessible Hg tutorials out there.

kissgyorgy 5 years ago

Mercurial is officially dead.

j0ba 5 years ago

This is disappointing. Bitbucket is the premier place to host free private mercurial repos. Just look at the hosting page on the mercurial website. There is literally not a single other place for free private hosting. There may be some smaller ones out there I'm not aware of.

Hacker news, question: Have you ever tried mercurial? Don't you like to save keystrokes? Isn't `hg com` easier than `git commit`? Isn't `hg pul` easier than `git pull`?

Is there any way to shorten the amount of keystrokes to use git?

  • chronial 5 years ago

    > Is there any way to shorten the amount of keystrokes to use git?

    Sure, you can just set up aliases in your shell and in git. Set an alias in your shell for git → g and in git for commit → c and you can commit with `g c`.

    • philpem 5 years ago

      There's a really good starter set in the Git manual:

      https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases

      I'm so used to "git co" and "git br" at this point (which are effectively analogues of the same commands on Hg) that I have to think for a minute when I SSH into a machine which doesn't have these set up.

    • j0ba 5 years ago

      Awesome, wasn't aware of git aliases. Thank you.

      • Arnavion 5 years ago

        Just be careful that if you define an alias that shadows a built-in command, your alias will be (silently?) ignored. Mostly a problem if a future version of git adds a command and clobbers an alias that used to work.

      • ad-hominem 5 years ago

        These are just aliases, they work with any shell commands, they're not git specific. Just fyi.

  • triceratops 5 years ago

    > Is there any way to shorten the amount of keystrokes to use git?

    Others have mentioned git aliases. But also, git recognizes some shortforms too. E.g. git rebase --con works the same as --continue. Doesn't work in hg.