For unfortunate reasons, at work we have intellij module files that are:

1. checked into git (because they are useful and hard to recreate)
2. changing all the time for no good reason (because intellij is a bit like that)

For the most part, the changes are just noise because paths, versions, etc. differ slightly across dev machines. Sometimes the differences are completely meaningless (unordered elements in a file being rearranged). But sometimes we do want to check in new versions of these files, say when we add a new module.

Since they are checked in, we can’t just add them to .gitignore. But we can still mentally ignore them, with this rather ridiculous hack:

$ git status | sed -E -e 's/\x1b\[[0-9][12]m(.*\.iml)/'"`tput setaf 3`"'\1/'

This changes the normally red (or green, or blue) lines in the git status output to yellow instead when they refer to an intellij .iml file. It’s completely hacky, but it’s better than breaking the build because you forgot to commit a file amongst all the noise.

You can put this in a script you call instead of git status - writing git status takes too long anyway, I just call my script g.

You’ll also need to make sure you have enabled colour “always” in git status output, otherwise you’ll get no colours at all:

$ git config --global color.status always

If anyone has a better way of ignoring files while having them checked in, I’d love to hear it. Do other VCSs allow you to deal with this any better?

I had to refer to this today, when I discovered (much to my surprise) that git submodules update does, for the most part, nothing.

You might expect it to update all my git submodules to the latest revision. Nope, I’m supposed to cd into each of those directories myself and run git pull myself.

The only hint that git update will do nothing of use is a single sentence in the help page, which mentions as part of the update command’s summary: “This will make the submodules HEAD be detached”. Which is a fairly unintelligible statement, even to someone who’s been using git for about a year now.

I can’t imagine when you would run git submodule update after the initial checkout - why doesn’t git submodule init just do update’s job (actually fetching the initial content), and then maybe we could have an update that actually pulls updates? I’d even be satisfied to have to use a flag, like --hard, --please or --come-on-old-chap-just-do-it-would-you

I’m pretty new to git’s submodules, and so far they just seem to take far too many manual steps (I don’t understand why they’re not fetched by a clone, for starters). I feel wrong saying so, but I miss svn:externals.

Tell me, how are things in the land of the other DVCS’s?

Update: Looks like my git is outdated, the newest version (1.6) allows a --merge or --rebase flag to update which sounds like it does what I want. Now I just need to sort out my mac’s package management :s

(view link)