Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm going to slowly move on from Mercurial

mercurial-scm.org

Post reply on HN
Print view View original

121–130 of 165 posts

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

#121

Post by alecdbrooks »

krupan wrote: post #106
slapresta wrote: post #100

Earlier quoted context omitted.

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" (Fa…

It seems to me that programming languages have far stronger network effects than any other example you or I are throwing out. If one project uses git and another mercurial and they want to work together, there are ways (hg-git, plain old patches). Try incorporating some java code in a ruby project, however. No possible way that is going to fly. Yet, we (at least the hacker news crowd) haven't declared any language as…

>Try incorporating some java code in a ruby project, however. No possible way that is going to fly.

I don't think this example is convincing. There are too many languages to expect arbitrary pairings to combine well. (Not to mention the fact that googling "java ruby" returns JRuby, which apparently lets you do just what you describe.)

I do agree with your last point: Even when we look at similar languages, like Python and Ruby, we don't declare one a winner, generally.

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

#122

Post by starseeker »

Karunamon wrote: post #120
bsder wrote: post #111

Earlier quoted context omitted.

> but on the availability of programmers who know how to use it The sheer prevalence of git "tutorials" would suggest that most programmers don't actually know how to use it. Relevant xkcd: https://xkcd.com/1597/

This comic is shockingly spot on for me and my group. We all know the basics, but only at a "type this to get this result" level. The moment something ridiculous needs to be done like a rebase, I get called, and without fail need to have a few stack overflow tabs open to figure it out. Git's a phenomenal system, but sometimes part of me thinks it does require a PhD to fully grok.

That's actually quite interesting - I remember similar comments (Phd required, or Phds aren't able to understand it) cropping up in discussions of the GNU autotools toolchain. (With a fair bit if justification, in my own experience, although I understand the results tended to be better for those who were shell script gurus...)

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

#123

Post by glandium »

jcranmer wrote: post #53
zeveb wrote: 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…

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™

Considering the number of tools based on the Git data model to do completely unrelated things (I'm thinking about e.g. bup or git-annex). I wouldn't say that's Git imposes you a One True Model. Also, Git doesn't restrict you to an arbitrary number of parents on a commit ;).

BTW,

> The Mercurial community seems to be working hard on making enormous monolithic repositories much more performant and realiable

The irony is that to do so, Mercurial had to bend its data model, adding (backwards incompatible) support for per-directory manifests (which sound a lot like trees in Git, except the part where manifests have history attached to them, where Git only has history attached to commits).

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

#124

Post by shadowmint »

School-Cotton wrote: post #16
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).

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.

Winning and 'being dead' are two things that mean different things to different people.

Git has at least an order of magnitude more people use it, and there is a significant and growing ecosystem around it that mercurial does not have.

Mercurial is not going to 'die' until the developers abandon it; you can still use and install it. Hell, even cvs isn't 'dead', and the last stable release was in 2008.

Mercurial will also continue to 'not be dead' for the foreseeable future, and people will use it for years to come.

...but it is already niche, and will increasingly become so.

Only time will tell, but I'd be shocked if you don't see more big name migrations away from hg over the next year or two.

People are important.

When your project forces them to use tools that don't like or don't know, they go else where. The impetus to change gathers more slowly in companies; but when you see announcements like this, like google code, like atlassian marginalizing hg, like cpython... it's crazy to suggest that it doesn't affect the way people think about mercurial.

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

#125

Post by carussell »

forty wrote: post #105
carussell wrote: post #93

Earlier quoted context omitted.

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-exp…

Can you explain what's the relation between git or mercurial and files' line ending convention and what problem there is? I have used both and never met this kind of problem

It's not Mercurial and Git line ending conventions, it's that Windows uses CRLF and Unix uses LF, and Git's approach to addressing this is pretty far short of good.

(Another pre-emptive response: yes I'm aware of both core.autocrlf and "text eol", but those are exactly the sort of sideways-cutting non-fixes that I'm talking about.)

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

#126

Post by glandium »

masklinn wrote: post #58
koenigdavidmj wrote: post #31

Earlier quoted context omitted.

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.

> 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. Not that this has changed much, the CLI git has been renamed to "git on windows" but fundamentally you're still installing msys (2) to run git. That issue is greatly mitigated by the existence of libgit2 though, it builds natively on windows (and just about…

> but fundamentally you're still installing msys (2) to run git.

You're installing msys to run git because (I guess) it was considered the git CLI would be useless without a decent shell. Would you see yourself use Git or Mercurial in cmd?

Git itself in Git for Windows, afaik, is not actually an msys program, and uses native win32 APIs.

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

#127

Post by rbehrends »

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.

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

The clean solution here is to stash/shelve the changes you don't want, then commit the ones you wanted. This works pretty much the same way in either VCS.

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

Use hg commit [-i], hg commit --amend [-i], and hg uncommit (with evolve) to modify the most recent commit as needed. Or, frankly, just use hg shelve [-i] to do the reverse as described above.

The Git index doesn't improve upon the situation, since you still can't test the partial commit without stashing the remaining changes first. At which point you could have just done that first.

In any event, the closest equivalent of Git's index in Mercurial is MQ, not hg commit -i and friends. The difference is that in Mercurial it's opt-in rather than opt-out.

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

#128

Post by JoshTriplett »

carussell wrote: post #125
forty wrote: post #105

Earlier quoted context omitted.

Can you explain what's the relation between git or mercurial and files' line ending convention and what problem there is? I have used both and never met this kind of problem

It's not Mercurial and Git line ending conventions, it's that Windows uses CRLF and Unix uses LF, and Git's approach to addressing this is pretty far short of good. (Another pre-emptive response: yes I'm aware of both core.autocrlf and "text eol", but those are exactly the sort of sideways-cutting non-fixes that I'm talking about.)

What's the behavior you expect, compared to the behavior that you get with git's configuration options?

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

#129

Post by JoshTriplett »

Karunamon wrote: post #120
bsder wrote: post #111

Earlier quoted context omitted.

> but on the availability of programmers who know how to use it The sheer prevalence of git "tutorials" would suggest that most programmers don't actually know how to use it. Relevant xkcd: https://xkcd.com/1597/

This comic is shockingly spot on for me and my group. We all know the basics, but only at a "type this to get this result" level. The moment something ridiculous needs to be done like a rebase, I get called, and without fail need to have a few stack overflow tabs open to figure it out. Git's a phenomenal system, but sometimes part of me thinks it does require a PhD to fully grok.

I think that comic also accurately describes the problem leading to that as well: it dismisses any explanation of Git's underlying mechanics and repository structure as ignorable rambling prefacing the command to do what you want.

It took me a while to learn git, and the explanations I went through involved the underlying structure of the repository. They seemed excessively complicated at the time, compared to memorizing commands for cvs and svn. However, now that I understand that underlying structure, every new git tool or function just provides additional means of transforming the repository structure I have into the repository structure I want.

You don't stop learning programming once you've memorized a rote sequence of steps to run a half-dozen algorithms on a hash table. And you don't stop learning git once you've memorized a rote sequence of steps to run a half-dozen algorithms on a git repository structure.

I don't mean that to suggest that git has no room to improve in its UI; far from it. But that particular comic seems to excuse a self-perpetuating problem of not wanting to learn something useful, and instead relying on people who did learn that useful thing while simultaneously belittling them for knowing it.

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

#130

Post by TylerE »

glandium wrote: post #126
masklinn wrote: post #58

Earlier quoted context omitted.

> 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. Not that this has changed much, the CLI git has been renamed to "git on windows" but fundamentally you're still installing msys (2) to run git. That issue is greatly mitigated by the existence of libgit2 though, it builds natively on windows (and just about…

> but fundamentally you're still installing msys (2) to run git. You're installing msys to run git because (I guess) it was considered the git CLI would be useless without a decent shell. Would you see yourself use Git or Mercurial in cmd? Git itself in Git for Windows, afaik, is not actually an msys program, and uses native win32 APIs.

Ever heard of a thing called powershell?
Post reply on HN