Live data from Hacker News

I'm going to slowly move on from Mercurial

mercurial-scm.org

31–40 of 165 posts

Re: I'm going to slowly move on from Mercurial

#31
post #12

Earlier quoted context omitted.

> Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. I remember using Mercurial very early on in its lifetime, during my first internship at IBM, because Xen used it. Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Me…

> Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Ouch, yet another way in which running on Windows can lead to poor technical decisions. In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over. > I originally saw the index as an o…

Hg worked on Windows from the beginning because it was written in Python. Python best practices make it pretty easy to avoid Windows-specific quirks (use os.path.join for directory munging, and don't use hard links). Git was a bit of C at first, which got wrapped in successive levels of bash and Perl, neither of which were particularly well supported on Windows 16 years ago.

Re: I'm going to slowly move on from Mercurial

#32
post #12

Earlier quoted context omitted.

> Lest we forget, Mercurial was offered as the other solution to the Bitkeeper problem, as mpm was a kernel hacker at the time. It got a usable UI at version 0.1, two weeks after the git announcement. I remember using Mercurial very early on in its lifetime, during my first internship at IBM, because Xen used it. Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Me…

> Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Ouch, yet another way in which running on Windows can lead to poor technical decisions. In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over. > I originally saw the index as an o…

> Ouch, yet another way in which running on Windows can lead to poor technical decisions.

Are you implying that choosing hg was a poor technical decision?

Or are you just making the general observation that if you include non-technical requirements when choosing a tool (and if we accept that running on a specific set of platforms is not a technical requirement...) then you might not end up with the choice that would have been best if all the requirements were purely technical?

If the former, then you should elaborate. As far as I was able to determine when I evaluated both hg and git is that they are essentially equivalent technically. Git's default interface makes some things visible that hg keeps behind the scenes, but these are all a quick hg extension installation away for those who want them.

Re: I'm going to slowly move on from Mercurial

#34

Matt has done a great job and I wish hg had taken off more than it did, though it would be disingenuous to suggest it hasn't been successful. I used hg before moving to git and always preferred the clean, single language implementation vs the scripts and general hackish nature that git offered as an alternative. As a result, it was a nice perk for a long time that hg worked much better than git on Windows.

Also the revsets, while they're relatively recent in the grand scheme of things (hg 1.6 circa 2010) I so miss these when I have to use (or even read the man page of) the garbage fire that is `git log` (templates also help)

I've actually converted a git repo to hg just to use revsets.

Re: I'm going to slowly move on from Mercurial

#35
post #13

hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).

hg came before git, you have your network effect backwards.

The reason git ended up overtaking mercurial is because git is more flexible. Programmers for closed-source enterprise projects worldwide flocked to git because git can be massaged into any existing development process almost painlessly.

Mercurial, in contrast, is "opinionated".

(Before you mention github -- the timeline here is also backwards, github became the de-facto standard riding on the coattails of git's success.)

Re: I'm going to slowly move on from Mercurial

#36
10+ years is a long time to steward a project. Most projects don't even live that long!

Transitioning away after 10+ years is a sign of several positive things:

* Creating a successful project that lasts 10+ years

* Having the perseverance, patience, and willpower to guide that project for its lifetime

* Creating a healthy community whom you are able to transition day-to-day responsibility of that project to

Matt has accomplished something that most of us never will. I'm envious of what he has accomplished and that he is able to walk away from a healthy and successful project. Truly a remarkable accomplishment.

Re: I'm going to slowly move on from Mercurial

#38
post #32
post #12

Earlier quoted context omitted.

> Mercurial also ran on Windows far, far earlier than Git did. A few projects (notably Mozilla) selected Mercurial for that reason, because they had developers on Windows. Ouch, yet another way in which running on Windows can lead to poor technical decisions. In my own case, I really preferred hg's command congruence to SVN; git's deceptive similarity took a long time to get over. > I originally saw the index as an o…

> Ouch, yet another way in which running on Windows can lead to poor technical decisions. Are you implying that choosing hg was a poor technical decision? Or are you just making the general observation that if you include non-technical requirements when choosing a tool (and if we accept that running on a specific set of platforms is not a technical requirement...) then you might not end up with the choice that would…

> As far as I was able to determine when I evaluated both hg and git is that they are essentially equivalent technically.

Today, yes. Significant work went into getting Mercurial's internals up to parity with Git's, and conversely into getting Git's UI up to parity with Mercurial's.

Re: I'm going to slowly move on from Mercurial

#39
post #13

hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).

hg-git[1] lets hg interoperate with git repositories, which helps a bit with the network effect problem. I'm currently using hg-git for my projects and I am loving it because I much prefer the hg UI (both the command line and tortoiseHg) to git's UI.

[1] https://bitbucket.org/durin42/hg-git

Re: I'm going to slowly move on from Mercurial

#40
post #20
post #13

hg could be 20% better than git. For the sake of the arugment, let's say it is. git's network effects mean hg needs to be 1000% better than git to replace it (much like git replaced svn, svn replaced cvs, and cvs replaced rcs).

TBH, I prefer Hg regardless. I only use git when forced to to interact with a project on GitHub. As for replacement, I don't think anyone wants that. Two widely used open source DVCSes is a great thing.

Have you ever tried out hg-git? It lets you interact with github repos using mercurial.
Post reply on HN