Hacker News Reader

Comment by koenigdavidmj | Hacker News Reader

http://www.python.org/dev/peps/pep-0374/#why-mercurial-over-...

Basically, they wanted a tool that was equally usable on all platforms, which excluded Git on Windows.

They also wanted something written in Python, of course, although they would have sacrificed that in the interest of pragmatism.

View on HN

In all fairness, I'd like to point out it's quite possible to make Git work on Windows. If one can adjust the path, it is also reachable through the same command line Windows folks are used to.

As far as I know, Git was a lot more awkward to use on Windows when they started discussing this move a few years ago.

I've found git to be a ---- nightmare to use. Part of that is inexperience, part of that its UX is a turd compared to hg.

Quite possibe to make work and works equally well are not the same thing. Mercurial is a breeze to install on Windows and any other platform, and with TortoiseHg's recent move to Qt, full cross-platform GUI support is also there (right now there are no Mac installers, but there should be some soon).

The last time I looked, Git on Windows required you use a different shell than the native Windows command shell (not that I'm a fan of the crappy Windows shell, but it does make it more awkward and feels less "native").

I think it's called Git Bash. It isn't so bad though, you get some working Unix commands with it. Come to think of it, I think it's better than CMD, to an extent.

I've been using MsysGit (Windows) for about 18 months as a "local vcs" wrapper around a sucky vcs (Accurev). Until the most recent MsysGit release, I used the "git bash" shell exclusively: for each Accurev workspace, I had a CMD shell where I ran builds in the w/s, and a git bash shell where I operate git for that w/s. This was mostly satisfactory (being able to write true bash scripts to automate git a tiny bit was cool), but when working with sometimes a dozen or more workspaces, it can get a little time consuming to locate the respective shell's mate. Anyway, MsysGit has mostly worked quite nicely for my limited purposes. However I am now evaluating hg as a possible replacement for Accurev (I'm running a quasi-import over the weekend). I'm also running a git import in parallel (mostly to compare repo size growth over time), and to do that (in lockstep) I'm running git from a CMD shell; so far I've not had any problems using git in CMD (wait, git's interpretation of the %EDITOR% environment variable in CMD is broken). Why hg, after all my experience with git? As mentioned elsewhere in this discussion: MsysGit (git for Windows) is like a "second class citizen"; it's pretty clear that the git creators have a negative religious attitude about Windows, thus expecting equal functionality and support on Windows is folly. The MsysGit discussion threads reflect a shoestring operation, with overwhelmed developers solely scratching their own itch (fair enough as far as it goes). Whereas hg treats Windows as a first class platform (presumably because it was designed and built with that in mind). I still like git's branching feature (which is why I chose it initially over hg), but between hg and git, hg is IMHO the only pragmatic choice for a "Windows shop".

Most people that use SVN on Windows seem to use TortoiseSVN instead of a command line.

Similarly, most Windows developers that I encounter who run Git just use TortoiseGit. (And TortoiseHg for Mercurial for that matter).

The whole "Git on Windows" issue? Completely overblown.

Yea, I do think that being written in Python was a big thing. It would be for me, if I were in their place. :)

Reply on news.ycombinator.com