== Why I've come to really like git

I [[mentioned on Twitter
https://twitter.com/thatcks/status/639469854479777792]] 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 ../tech/MercurialVsGitII]],
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 GitCommitAndRebaseBetter]] and when
[[working on my own stuff GitMultiRepoWorkflow]]. Rebasing (and
[[things it enables CommitLittleChanges]]) 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 GithubPRTestingWorkflow]]. 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.)