Thank you, Matt. hg is still my choice in source control. It's the only one I really use.
I'm going to slowly move on from Mercurial
61–70 of 165 posts
Re: I'm going to slowly move on from Mercurial
#62hg 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).
There are tons of companies using mercurial including some of the biggest ones. It's not really accurate to imply that Git won and Mercurial is dead.
There are tons of companies using Lotus Notes. git won.
Re: I'm going to slowly move on from Mercurial
#63Earlier 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…
> I originally saw the index as an obstacle to the commit model I'd gotten used to from subversion. Today, I find it a critical part of git's culture of making small commits with one logical change each. How is this different from mercurial ? I know that the latter doesn't have the index, but is there any practical difference from the point of view of the user ? In Mercurial you can easily commit a subset of the file…
Have you used both?
You can commit a subset of changed files in most version control systems, but it isn't smart because you didn't test that state and it's relatively easy to garble files.
Not having the index is a very practical difference for users, because it means that you do not get any editable "staging" commits, only commits that will be on the permanent record.
Re: I'm going to slowly move on from Mercurial
#64Earlier 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…
"I find [the index] a critical part of git's culture of making small commits with one logical change each." I've never understood why the index has to be forced on everyone for every commit. Apparently it's due to a belief that everyone always just munges a bunch of changes together in their working copy in a mad coding frenzy and then later realize they need to filter and separate those changes into separate commits…
In recent versions the "record" extension has been replaced by "hg commit -i". Many other commands support interactive hunk selection as well.
Re: I'm going to slowly move on from Mercurial
#65Earlier quoted context omitted.
Except unlike your examples, hg was contemporaneous with git. Git may have won the network effect benefit but 10 years ago it was not at all clear how it would shake out. Mercurial did gain enough users (and large users) to remain relevant, unlike some of the other options at the time.
Well yes, that's the point! It would have never been the replacement for git because it's the same paradigm. rcs: revision control cvs: concurrent check outs svn: atomic versioning (edit: originally said renames that don't suck - thanks Danny for correcting this) git: decentralised version control To replace git, you need a new paradigm. I don't know what it is, and I think few people here would. Edit: to reiterate,…
>To replace git, you need a new paradigm. I don't know what it is, and I think few people here would
um.... how about a good command-line UI that doesn't require remembering all sorts of crazy command line switches?
Re: I'm going to slowly move on from Mercurial
#66hg 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…
> hg came before git, you have your network effect backwards.
Can you explain? Not sure how hg being released earlier changes how many users they have. See https://en.wikipedia.org/wiki/Network_effect
Re: I'm going to slowly move on from Mercurial
#67Earlier quoted context omitted.
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.
i've never tried. but i usually refrain from putting more technology than needed to reach my end goals.
less is more, in this case. :P
Re: I'm going to slowly move on from Mercurial
#68Earlier 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…
It's worth pointing out that part of the reason that Mozilla selected Mercurial over Git was that the Mercurial developers were more willing to help fix issues that Mozilla had identified than Git was, with Windows support being the most important point. In a way, actually, that still seems to be the case. The Mercurial community seems to be working hard on making enormous monolithic repositories much more performant…
> So there's definitely a sense to me that Mercurial is the better VCS because it will quietly support whatever development model you want to use, whereas Git tries to force you to use the One True Model™
Wow, I can't disagree with that notion more. I've been on many projects that use git and practically every one used git in different ways. I've never felt that git was trying to force a particular workflow on me. Git's greatest strength, to me, has always been its toolbox nature—you can make it do whatever you like (want to comb through your entire repo and change someone's email address, or backdate an entire branch? No problem!).
Re: I'm going to slowly move on from Mercurial
#69Earlier quoted context omitted.
There are tons of companies using mercurial including some of the biggest ones. It's not really accurate to imply that Git won and Mercurial is dead.
I consider the CPython switch from Mercurial to git the final declaration of victory. I still have to understand how CPython could miss the symbolic meaning of this decision.
imho for CPython, the decision was more of the network effect that Github have rather than picking any particular tool or language. I Know Gitlab was also taken into account, and RhodeCode as well which supported Mercurial and itself is also written in Python. I think in there days for large OS projects it's more important to have more potentials contributors rather than sticking to only Python projects. Just my 2c.
Re: I'm going to slowly move on from Mercurial
#70Earlier quoted context omitted.
Except unlike your examples, hg was contemporaneous with git. Git may have won the network effect benefit but 10 years ago it was not at all clear how it would shake out. Mercurial did gain enough users (and large users) to remain relevant, unlike some of the other options at the time.
Well yes, that's the point! It would have never been the replacement for git because it's the same paradigm. rcs: revision control cvs: concurrent check outs svn: atomic versioning (edit: originally said renames that don't suck - thanks Danny for correcting this) git: decentralised version control To replace git, you need a new paradigm. I don't know what it is, and I think few people here would. Edit: to reiterate,…
Except its not the DCS paradigm that led to git's network effect. In fact, for the vast majority of users they are using it as a de-facto centralized system (on github).
DCS was around before git and did not sweep the tech industry. Just like concurrent check outs weren't the reason cvs took off.