Hacker News new | comments | show | ask | jobs | submit login

You might give Mercurial a shot. It's the speed of Git with a much saner user experience. Plus, all the power of Git's there; it's just hidden under the covers until you need it.

Speaking of the examples in this article:

    hg update
allows you to fast-forward without making a commit. The equivalent of

    git checkout
in Mercurial is (roughly)

    hg update -c
which will refuse to update if you have changes. (You can override that with "hg update -C".)

In the case of merge output, when you've fixed a file, you simply run

    hg resolve filename
You can at any point see what's not merged by running

    hg resolve --list
Notably, if you have a three-way merge tool set up properly, you'll never do this, because Mercurial will walk you through doing the merge properly as part of the...well, merge.



"It's the speed of Git..."

No it's not. Speaking from experience here.

Edit: Okay, here's some real data: http://git.or.cz/gitwiki/GitBenchmarks http://whygitisbetterthanx.com/#git-is-fast

It shows that git wins by most metrics, with a few exceptions. Mercurial's push/pull format is particularly good.


Speaking from my own experience, we're talking about, at most, maybe a 5% speed penalty in some operations; most others happen instantly on both systems. Can you provide a concrete example where Mercurial's noticeably slower than Git at the same operation?

Edit in response to above edit: those stats are for Mercurial 0.4 through 0.9.5. The current version is Mercurial 1.3.1. Seeing as there have been piles of speedups, including several that fell out from Python modules getting rewritten in C, I find that page highly dubious.


What sort of hit? Is it just a bit pokier or does it get really bad for anything in particular? Anyone got any actual data?


>> "Anyone got any actual data?"

Is the SPEED of any revision control system ever an issue? To anyone? Surely it's 'fast enough that it doesn't matter' vs 'fast enough that it doesn't matter'


Yes, when a command takes a couple seconds to perform, you don't consider doing it unless you have a really good reason.

Classic hg branching came into different forms: 1) a tree clone and 2) the hg "branch" commands.

1 can be very slow on a large tree and can often require you reconfigure your tools to go look in a new place.

2 is permanent. Your code now forever references the name of a branch so you have to stop and think about whether it's really the right thing to do.

In either case, anything that requires me to stop and consider the cost of an operation makes the operation less valuable. Where that cost kicks in varies for people. Is it minutes? Seconds?

As a former perforce user, there were definitely plenty of things I wouldn't do there because they weren't instant. In git, I tend to make decisions based solely on my desired outcome.


I'm not sure about git vs hg, but I'd definitely say that the speed of git is a win vs svn.

For example, running status to see the state of the working directory. With svn it takes a couple of seconds on small repositories, and it can easily climb above ten seconds on larger repos. With git it very rarely rises above a second, even with a cold disk cache. The difference in speed is large enough that I find myself running "git status" far, far more often than I ever ran "svn status".

A more dramatic example is 'git bisect' which, when given a command, it will do a binary search on the repository to find the commit which caused that command to begin to fail (return an exit code of something other than 0).

Speed is a feature.


> Is the SPEED of any revision control system ever an issue?

Yes, darcs used to have (and probably still has, though to a lesser level) an issue with merge times blowing up exponentially. Anyway stevejohnson took issue with the statement that Mercurial performed roughly on part with Git, you might want to take the issue up to him not davidw.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: