I mentioned on Twitter that I've completely flipped my view of git (and Mercurial) around, to the point where I actively like using git and want to be using git for things. This goes beyond where I used to be, where I simply felt that git was the right thing to learn and use going forward for relatively pragmatic reasons. Part of this is undoubtedly just increasing familiarity with git (it's hard not to feel good about something you use a lot), but I can also point to specific things that I really like about git.

The first is git rebase and everything around it, both when dealing with other people's projects and when working on my own stuff. Rebasing (and things it enables) has clearly made my life easier and nicer, especially when carrying my own modifications on top of other people's software. Interactive rebasing also makes it easy to manipulate my commits in general to do things like shuffle the order or squash several commits together. Perhaps there are other tools for this, but I already need to know rebasing, so I've opted to keep my life simple.

The second turned out to be git's index. There are two primary things I love about the index: it lets me see definitely and exactly what I'll be committing before I do it via 'git diff --cached' (which I use so much I have an alias for it), and it easily lets me make and check selective commits. Of course in theory I shouldn't need to make selective commits because I should be working selectively to start with. In practices, no, I don't naturally wind up working that way so it's great to be able to methodically untangle the resulting messy work tree into a series of neat commits by staging things through the index.

(That the index is explicit is very important here for me, because it means I can stage things into the index, see the diff, and then say 'oops, no, I left something out' or 'oops, no, I put too much in, let's try that again'. An on the fly single pass 'select and commit' model demands that I get it right the first time with little margin for error. With the index I can abort right up to the point where I complete 'git commit' and I haven't lost any of my prep work so far.)

The third thing is 'git grep', or more specifically the fact that the git people have somehow made it amazingly fast. 'git grep' is clearly much faster at searching repos (especially big repos) for things than normal 'grep -r', 'find | grep', and so on. Since a bunch of what I do with other people's repos is fish through them trying to find things, this is really great for me; I can search the Linux kernel repo, the Illumos repo, and so on fast enough to make it a casual thing to do. By contrast, finding things in the Mozilla Mercurial repo is always a comparatively slow pain.

(Mercurial has 'hg grep', but it does something completely different. What it does is useful but something that I want much less often.)

Although I can't point to anything big in specific, in general I've wound up feeling that git makes it easier (and possible) to manipulate my repos in crazy ways if I really need to. I suppose 'git filter-branch' is the poster child for this (although the feature I wound up caring about has been mostly wrapped up as 'git subtree split'), but I've also used things like changing the upstream of branches. Basically it feels like if git can possibly support something, it will somehow and I can make things work.

(I may discover additional nice things about git in the future, but this is my current list of things that really affect me when I work with a git repo versus eg a Mercurial repo.)