By "git index", do you mean the git staging area (the place where you assemble your commit before you actually commit it)? If so, that's not a pain, it's one of git's best features. It takes some getting used to, that's true, but once you do systems that don't have it start feeling crippled.
As someone who has switched from Mercurial to git for all projects where I have a choice, I'd give git's advantages as roughly these:
* Much larger developer community, meaning that git itself and tools around it have a considerably faster pace of development.
* The staging area, which enables workflows that plain aren't possible in hg. Not least including the ability to only commit part of the changes in a file, unless hg has gained that ability since I stopped using it.
* At least back then, git was much, much faster than hg.
* git has the ability to re-order and merge commits, so you can commit as often as you like while you work and still present a logical progression of commits when you push to the rest of the world. Differently put, you can clean out "fixed typo" commits so the world doesn't have to see them.
no subject
As someone who has switched from Mercurial to git for all projects where I have a choice, I'd give git's advantages as roughly these:
* Much larger developer community, meaning that git itself and tools around it have a considerably faster pace of development.
* The staging area, which enables workflows that plain aren't possible in hg. Not least including the ability to only commit part of the changes in a file, unless hg has gained that ability since I stopped using it.
* At least back then, git was much, much faster than hg.
* git has the ability to re-order and merge commits, so you can commit as often as you like while you work and still present a logical progression of commits when you push to the rest of the world. Differently put, you can clean out "fixed typo" commits so the world doesn't have to see them.