the corner office : tech blog

I've been using git for a few months, but I don't yet know how some parts of it work. One thing I haven't understood entirely is the index - mainly because it's (mostly) possible to chug along using git as it if were CVS or Subversion - do some work, git status to see what's changed, git diff to see changes, git add to add new files, git commit to get it committed.

I say mostly, because there is this shifting-sandish ground where things go wrong or where git diff and git status don't tell me what I expect. I've always known this is due to the 'index', but not really understood how it works.

I have a better idea now, but it's not entirely clear yet. The main thing I read is that it allows one to tailor commits, and to differentiate between known-good commits and stuff for review (which is what git diff shows). I'm not sure whether the intention is broadly different to (or, at this stage, better than) Perforce's changelists, which allowed you to group up changes. I hated Perforce with a passion when I used it, but changelists where the one thing I really liked.

This Stackoverflow discussion seems to be saying, roughly, that git branches are the equivalent to changelists, but that's not entirely true, since branches aren't concurrent. You could argue that it's safer not to have different changelists on the same code base (and it's a common issue in Perforce world where a particular changelist has an overlooked dependency on a change in another changelist and breaks a build), but on balance, when you're comfortable that changes are mutually exclusive, multiple change lists are a useful feature to have.