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…
I'm going to slowly move on from Mercurial
31–40 of 165 posts
Re: I'm going to slowly move on from Mercurial
#32Earlier 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…
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
#33Re: I'm going to slowly move on from Mercurial
#34Matt 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)
Re: I'm going to slowly move on from Mercurial
#35hg 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).
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
#36Transitioning 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
#37Re: I'm going to slowly move on from Mercurial
#38Earlier 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…
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
#39hg 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).
Re: I'm going to slowly move on from Mercurial
#40hg 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.