named branches
http://hgbook.red-bean.com/hgbookch8.html#x12-1570008

git-like (local only) branches
http://www.selenic.com/mercurial/wiki/index.cgi/BookmarksExtension

rebase support
http://www.selenic.com/mercurial/wiki/index.cgi/RebaseProject

The past two days I basically came to the same conclusion again, allthough I was briefly fooled that git windows support was looking brighter this time around, only to realize it looks insanely dark.

Windows explorer integration projects ToroiseGit and CheetahGit are DEAD. I think this can’t be stressed enough for anyone that needs to work with windows, and thinks that these are on the horizon to salvage the situation.

The elitist attitude from some of the Git people, is alienating and highly counter productive. I think this should also be considered as a con when comparing the different solutions. Because if you need windows, and one solution is full of anti-windows folks, it doesn’t bode well.

What really irked me was reading the thread/comments here:
http://kerneltrap.org/mailarchive/git/2008/10/31/3874054
http://code.google.com/p/msysgit/wiki/GitCheetah

hilights such as:

“the big problem is: I do not want many people on Windows to convert to Git, since my experience is that they — expect other people to work for them. IOW I would not get anything except for some thankyous for my work”

“and from what I’ve seen of tortoise* users, ’stupid proof’ is very, very, very, necessary”

This elitist and anti-UI attitude that seems to be surrounded by git really ticks me off. He can cry about windows users not contributing until his face turns blue, but the strangely enough the other Tortoises (including TortoiseHg) actually are getting done, people are working on them. Maybe, just maybe, there is an attitude problem going on that keeps people away from that particular project.

Mind you, I’m a linux/*nix fan and user and have been for 15+ years. Yes yes MS sucks and all that, but I still need to work on windows for most things. The more platforms a solution can support, the merrier. Mercurial doesn’t seem ooze of anti-windows as git does, which is a shame, as I really really wanted to go with git. But basic UI support is a must, it’s 2009 for christsakes (it has nothing to do with intelligence), I still use the command line, and like it, for some things, everything has its place and time.

$ ls -l git git-add
-rwxr-xr-x 88 root root 823536 2008-08-25 06:40 git
-rwxr-xr-x 88 root root 823536 2008-08-25 06:40 git-add

$ stat git git-add
File: `git’
Size: 823536 Blocks: 1616 IO Block: 4096 regular file
Device: 2103h/8451d Inode: 25477044 Links: 88
…
File: `git-add’
Size: 823536 Blocks: 1616 IO Block: 4096 regular file
Device: 2103h/8451d Inode: 25477044 Links: 88
…

Both binaries use the same inode, so they’re hard links! Also note the link count — this means at least 88 of the 149 git binaries are actually only hard links to a single binary on the disk — even though it APPEARS as though there are multiple copies. Usually this is done with soft links instead, which stand out as being links rather than files, but for some reason hard links were chosen in this case instead… very interesting.

1. ‘git reset –hard’ is enough, because it defaults to HEAD if no commit is given.

2. Alternatively, you can do a whole-tree revert with ‘git checkout .’ (while in the root directory of the repository), so the UI is not that inconsistent anymore. But it might be frustrating to svn users, because ‘git checkout’ and ’svn checkout’ do different things.

“The equivalent command for svn revert in git is git reset –hard HEAD^.”

It is ‘git reset –hard HEAD’, without the ^ at the end, which is a fundamental difference.

However, if you want to do ’svn revert some/file’, then it’s ‘git checkout some/file’. Oh well.