Why I've come to really like git
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. '
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
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 '
filter-branch' is the poster child for this (although the feature
I wound up caring about has been mostly wrapped up as '
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
(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.)
Comments on this page:Written on 13 October 2015.