Every once in a while, I find myself working on a project that forces me to modify key files—often config files—in order to get it running locally. In those cases, the last thing I want to do, for a number of reasons, is to commit those changes. That’s hard to do, though, since I regularly use git add . and/or git ci -a to commit everything I’ve changed. Make enough changes in enough files that you don’t want to commit and these changes begin to cause as many problems as they solve.
As is so often the case, it seems, Git comes to the rescue with its update-index command. Reading the documentation, it’s not really intended for this purpose, but its effectiveness as a “coarse file-level mechanism to ignore uncommitted changes in tracked files” is recognized. To apply it, simply make a change to a committed file, say, database.yml and execute git status. Git should report the modified file. Since we don’t want to commit, we don’t want to see this listed as a modified file until the end of time and we can’t ignore it (because it’s already being tracked), we need to tell Git to assume the file is not changed.
git update-index --assume-unchanged path/to/database.yml
I’ve been using this command since I learned of it a few weeks ago and it works perfectly for this use case. Inevitably, though, a question will arise:
What files have I marked this way?
Since those files will no longer appear in the modified list, can’t be easily found in a .gitignore file or exposed by removing a .gitignore file, there will eventually be a need to know this. Maybe you’re trying to get another instance running or maybe you’re just the curious sort and you’ve forgotten. Like many things in Git-land, the functionality exists, but is far from obvious. I asked on StackOverflow and Andrew Aylett provided the answer I was looking for.
If you ever find yourself needing to know, this command will display the files that have been marked as —assumed-unchanged.
git ls-files -v | grep -e "^[hsmrck]"