Can I 'git commit' a file and ignore its content changes?

Every developer on my team has their own local configuration. That configuration information is stored in a file called devtargets.rb which is used in our rake build tasks. I don't want developers to clobber each other's devtargets file, though.

My first thought was to put that file in the .gitignore list so that it is not committed to git.

Then I started wondering: is it possible to commit the file, but ignore changes to the file? So, I would commit a default version of the file and then when a developer changes it on their local machine, git would ignore the changes and it wouldn't show up in the list of changed files when you do a git status or git commit.

Is that possible? It would certainly be a nice feature...

Sure, I do exactly this from time to time using

git update-index --assume-unchanged [<file> ...]

To undo and start tracking again (if you forgot what files were untracked, see this question):

git update-index --no-assume-unchanged [<file> ...]

Relevant documentation:

> --[no-]assume-unchanged
> When this flag is specified, the object names recorded for the paths are not updated. Instead, this option sets/unsets the "assume unchanged" bit for the paths. When the "assume unchanged" bit is on, the user promises not to change the file and allows Git to assume that the working tree file matches what is recorded in the index. If you want to change the working tree file, you need to unset the bit to tell Git. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs). > > Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, you will need to handle the situation manually.

Fail gracefully in this case means, if there are any changes upstream to that file (legitimate changes, etc.) when you do a pull, it will say:

$ git pull
…
From https://github.com/x/y
   72a914a..106a261  master     -> origin/master
Updating 72a914a..106a261
error: Your local changes to the following files would be overwritten by merge:
                filename.ext
 

and will refuse to merge.

At that point, you can overcome this by either reverting your local changes, here’s one way:

 $ git checkout filename.ext

then pull again and re-modify your local file, or could set –no-assume-unchanged and you can do normal stash and merge, etc. at that point.

The preferred way to do this is to use git update-index --skip-worktree <file>, as explained in this answer:

> assume-unchanged is designed for cases where it is expensive to check > whether a group of files have been modified; when you set the bit, git > (of course) assumes the files corresponding to that portion of the > index have not been modified in the working copy. So it avoids a mess > of stat calls. This bit is lost whenever the file's entry in the index > changes (so, when the file is changed upstream). > > skip-worktree is more than that: even where git knows that the file > has been modified (or needs to be modified by a reset --hard or the > like), it will pretend it has not been, using the version from the > index instead. This persists until the index is discarded.

To undo this, use git update-index --no-skip-worktree <file>

Since git version 2.25.1, this is no longer the recommended way either, quoting:

>Users often try to use the assume-unchanged and skip-worktree bits to tell Git to ignore changes to files that are tracked. This does not work as expected, since Git may still check working tree files against the index when performing certain operations. In general, Git does not provide a way to ignore changes to tracked files, so alternate solutions are recommended. > >For example, if the file you want to change is some sort of config file, the repository can include a sample config file that can then be copied into the ignored name and modified. The repository can even include a script to treat the sample file as a template, modifying and copying it automatically.

Common practice seems to be to create a devtargets.default.rb and commit it, and then instruct each user to copy that file to devtargets.rb (which is on the .gitignore list). For example, CakePHP does the same for its database configuration file which naturally changes from machine to machine.

For IntelliJ IDEA users: If you want to ignore changes for a file (or files) you can move it to different Change Set.

• Head over to Local Changes (Cmd + 9)
• Select file(s) you want to ignore
• F6 to move them to another Change Set

It is not possible to ignore changes to a tracked file with Git. The Git FAQ explains this:

> Git doesn’t provide a way to do this. The reason is that if Git needs to overwrite this file, such as during a checkout, it doesn’t know whether the changes to the file are precious and should be kept, or whether they are irrelevant and can safely be destroyed. Therefore, it has to take the safe route and always preserve them. > > It’s tempting to try to use certain features of git update-index, namely the assume-unchanged and skip-worktree bits, but these don’t work properly for this purpose and shouldn’t be used this way.

If your goal is to work with a configuration file, then the best thing to do is add an example or template file and then either have the user copy it into place or have a script create the appropriate file. You should then ignore the location of the actual configuration file and only check in the example or the template.