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.
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'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".
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 find the way your phrase that question interesting. Git and Mercurial are nearly identical in terms of functionality, to the point that converting back and forth between them is pretty trivial. (Example: here's Git's repository in Mercurial https://mirrors.kilnhg.com/Repo/Mirrors/From-Git/Git)
The only real difference between the two are the ecosystems. Mercurial, being written is Python, is very portable and easily extensible. I feel like, because of that, the tools for Mercurial are better. Git has GitHub, and the incredible open source community they've developed there.
* Note, the rainbow road is due to one of the few differences between Git and Hg: Hg does not allow octopus merges, so the conversion turns them to a sequence of two at a time merges. Also, in the interest of full disclosure, I'm one of the devs on Kiln, so I'm certainly biased towards Hg.
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.
`histedit` does what `rebase -i` does, `hg rebase` does what `rebase` does.
There are a few limitations to `histedit` compared to `git rebase -i` I think: I believe it's possible to split revisions using `rebase -i`, I don't think that can be done using histedit (it has pick, edit, drop and fold). Histedit also misses the (pretty recent I believe) `exec` action of git's rebase -i.
hg branches are entirely different from git branches, so resetting them in that way doesn't make sense. The closest approximation - bookmarks - can indeed be reset (hg bookmark -f).
histedit does a variety of things; I'm not sure if it covers all of rebase's branches. Mercurial does also have a rebase facility now as well.
Hg seems to have evolved several vaguely similar but isolated optional features (named branches, local branches, bookmarks, patch queues) which I guess means they haven't arrived at one everybody's happy with. Some people even prefer to keep hg branches in cloned repos, which sounds very painful. Git handles all those use cases by binding a ref to a commit and calling it a branch (even stashes are stored as branches, just more difficult to push).
> histedit does a variety of things; I'm not sure if it covers all of rebase's branches. Mercurial does also have a rebase facility now as well.
That is correct. In Mercurial, git's `rebase` is (sensibly, as far as I am concerned) split into two different commands: `histedit` handles the history edition within a branch and `rebase` handles the rebasing of a branch on a revision of an other branch.
While mercurial being written in python is noted[1] , it is made explicitly clear, its not the reason behind the main selection of Hg as the version control.
"First, git's Windows support is the weakest out of the three DVCSs being considered which is unacceptable as Python needs to support development on any platform it runs on."
This is FUD! The support for git on windows is pretty good and there is nothing obstrusive in it. You can use git on Windows fairly well. Sad to see this kind of comment written by smart people.
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.
Trolling aside, that's the only reason I chose hg over git for my projects -> sane approach to the UI. With both of them having more or less the same functionality, UI of git is... inconsistent at the very least.
