Git’s update-index’s assume-unchanged vs skip-worktree

We have some config files on my companies app which I need to change for my local install to work. I was using git update-index --assume-unchanged to ignore my local changes. This allowed me to switch between branches and commit

The downfall to this is that this file hasn’t been touched in months and I have a poor memory (?) and when the file was recently changed by a co-worker and merged by me my changes were simply overwritten.

I was then unable to log in to my local app and got distracted in trying to find out how a recent SSO addition (which was working locally when I first merged) stopped working. I should have started from the basics of my local install and made sure all was in order. In any case, I didn’t, and it took me 3 or 4 hours debugging SSO to get around to it.

All of this could have been avoided, by using the skip-worktree flag instead of assume-unchaged

assume-unchanged seems to have a performance related goal. Here’s something from the docs:

Many operations in Git depend on your filesystem to have an efficient
       lstat(2) implementation, so that st_mtime information for working tree
       files can be cheaply checked to see if the file contents have changed
       from the version recorded in the index file. Unfortunately, some
       filesystems have inefficient lstat(2). If your filesystem is one of
       them, you can set "assume unchanged" bit to paths you have not changed
       to cause Git not to do this check. Note that setting this bit on a path
       does not mean Git will check the contents of the file to see if it has
       changed -- it makes Git to omit any checking and assume it has not
       changed.

Perhaps because of that focus, it does not throw a conflict when a merge would overwrite your changes.

git update-index --skip-worktree <file_name>
git ls-files -v|grep '^S'
git update-index --no-skip-worktree <file_name>