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.

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.

Relative occurence numbers don't say much about the need for octopus. Maybe they're rare but when the need arises it proves to be an invaluable feature.

I meant "git reset --hard" as a prefix for useful <refspecs>.

Can hg set the current branch to point anywhere in time?

Does histedit do exactly what "rebase" does? Does it also work with "--onto" and other rebase features?

hg: unknown command 'histedit'

"Last-Modified: 2010-01-07 23:33:01 +0100 (Thu, 07 Jan 2010)"

The PEP was written in 2008.

Git's Windows support is clearly the weakest since it requires either MinGW or Cygwin. The platform itself is unoptimized for native Windows performance. It may not be terrible but it's certainly the weakest of the DVCSs, as they say.

Last time I tried TortoiseGit, adding a file either didn't work or just crashed hard. Mercurial, on the other hand, just got TortoiseHg 2.0, which is a pleasure to work with.

It is true that git works on Windows, but that doesn't mean it works well.

I've been working on a prject last year which involved a few developers using Windows. It was a nightmare. Myself using Linux, i had no problem. But git on Windows.. It'd definitely behind other VCS.