I'm going to slowly move on from Mercurial • Hacker News Board

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

#91

Post by solomatov » Mon, Jan 25, 2016, 9:36 PM UTC

IshKebab wrote: post #29

nailer wrote: 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).

Yeah by "git's network effects" you mean github. If github had decided to be hghub instead, hg would probably have won.

You don't take into account tooling. There're more options for tools which work with git than for hg. Also, git support is usually more stable and better tested.

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

#92

Post by krupan » Mon, Jan 25, 2016, 10:02 PM UTC

pekk wrote: post #63

mrighele wrote: post #43

Earlier quoted context omitted.

> 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.

But nothing in git (or any dvcs, really) is "permanent record" until you share it with others. git users are very proud of git's history editing capabilities, in fact. So no need for an index, just commit, and edit that commit if needed.

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

#93

Post by carussell » Mon, Jan 25, 2016, 10:02 PM UTC

JoshTriplett wrote: post #38

tzs wrote: post #32

Earlier quoted context omitted.

> 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.

Respectfully, Git still has a long way to go before it achieves parity with Mercurial, or even its state of the art from, say, 2010.

Don't discount the effect that familiarity with a tool or process can have on your perception of it. The most succinct explanation of this effect that I know comes from the title of a post on the Light Table blog called, "Pain We Forgot".

Coming from a Mozilla-influenced, pre-GitHub-explosion background, I'm one of those people always favored Mercurial but used both out of necessity. Mostly that meant using hg for my own stuff that is most likely never to see the light of day and git for almost everything else. But I also ended up calling it quits on Mercurial and pulled the trigger on git-for-everything last week.

So, having just written (what should be a completely unnecessary) tool to dump out stats about files' line ending conventions, again, I'll say that Git has a long way to go.

(And before you ask, yes the problem manifests itself using the latest version of Git, and there's nothing exotic or wacky to my workflow, nor am I witnessing the effect of interplay with other tools of dubious quality. This is an outright case of Git's tendency to drop the ball and then gesture in the vague direction of a poorly documented non-fix that cuts orthogonally to the problem it's supposed to be solving.)

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

#94

Post by krupan » Mon, Jan 25, 2016, 10:04 PM UTC

rbehrends wrote: post #90

JoshTriplett wrote: post #6

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…

A couple of technical notes: > such as a repository structure optimized for performance Actually, repository structure hasn't fundamentally changed (unless you count the RevlogNG change in 0.9). There have been changes so that data on disk compresses better (the generaldelta change) and there's more underway to support new features (such as narrow clones), but they generally aren't performance-related. I note that th…

Thank you for correcting. There is so much misinformation about mercurial out there.

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

#95

Post by stevelosh » Mon, Jan 25, 2016, 10:05 PM UTC

I've only contributed a few patches to Mercurial but meeting Matt and learning from him (mostly on the HG mailing lists) has taught me a lot. He's influenced how I think about and work with code at a really basic level. I wish him the best in whatever he decides to do.

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

#96

Post by rjbwork » Mon, Jan 25, 2016, 10:12 PM UTC

ufo wrote: post #40

rjbwork wrote: post #20

Earlier 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 have. TBH it was more trouble than it was worth, and I had some trouble with the initial setup. It was a couple years ago now though, so it's possibly gotten better.

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

#97

Post by krupan » Mon, Jan 25, 2016, 10:19 PM UTC

I'm really surprised by the "git won" mentality that manifests in any discussion of mercurial as of late. It makes no sense. We don't decare "winners" with other tools we use. Do we?

Why are we all playing with new programming languages when C won? Or maybe C++ won? Or Java? Did emacs or vim win? Speaking of text, did ASCII win? Which code review tool won? How about continuous integration tools? or build tools? I mean, make won, right?

None of us just pick the most widely used tool or programming language and say, "there can only be one" and then stop trying new things. Why are we doing this with version control?

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

#98

Post by yeukhon » Mon, Jan 25, 2016, 10:21 PM UTC

I did a project on integrating Mercurial with Mongo before, and I have to say being a Python developer I didn't have too much difficulty in figuring the right API, although the documentation is not so great. The code itself uses a lot of abbreviations which you have to really be patient to get familiar. The Mercurial model [1] is a pleasant read for a couple train ride (read it a few times I encourage). Others have done amazing things with hg too, like making hg available in Javascript (now an abandon project).

Mercurial is actually very easy to use. However, it didn't have the exact lightweight concept of git branch until they implemented bookmark a few years ago. I don't remember the limitation of bookmarks now it has been a few years since I used Mercurial...

I too thank Matt and core developers working on Mercurial. One thing I feel Matt and developers need to address is hosting hg on PyPI infrastructure instead of redirecting to their own server. From time to time the server wouldn't deliver anything and it was frustrating to see our builds fail (of course some say you should have cached the build and not hitting Mercurial server every day).

[1]: https://www.mercurial-scm.org/wiki/Presentations?action=Atta...

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

#99

Post by Avshalom » Mon, Jan 25, 2016, 10:24 PM UTC

krupan wrote: post #97

I'm really surprised by the "git won" mentality that manifests in any discussion of mercurial as of late. It makes no sense. We don't decare "winners" with other tools we use. Do we? Why are we all playing with new programming languages when C won? Or maybe C++ won? Or Java? Did emacs or vim win? Speaking of text, did ASCII win? Which code review tool won? How about continuous integration tools? or build tools? I mea…

While emacs and vim are still duking it out people are CONSTANTLY defaulting to or arguing the case for this or that because "the right tool for the job" 90% of the time means "the tool the community supports for my problem"

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

#100

Post by slapresta » Mon, Jan 25, 2016, 10:37 PM UTC

krupan wrote: post #97

I'm really surprised by the "git won" mentality that manifests in any discussion of mercurial as of late. It makes no sense. We don't decare "winners" with other tools we use. Do we? Why are we all playing with new programming languages when C won? Or maybe C++ won? Or Java? Did emacs or vim win? Speaking of text, did ASCII win? Which code review tool won? How about continuous integration tools? or build tools? I mea…

Code collaboration tools have a strong network effect due to them being ultimately social tools, and we expect categories affected by the network effect to have winner/losers mechanics. Of course, they don't actually have to, but it's a common expectation and a common outcome.

For equivalents to "code collaboration tools", instead of "programming languages", "text editors" and "build tools", try "social networks" (Facebook won, MySpace lost), "network protocols" (HTTP won, FTP and Gopher lost) or "spoken languages" (English won)