Ironically, while git’s default behavior is to treat untracked files as precious, adding the file to .gitignore
tells git that it can trash the file whenever it wants.
Entries in .gitignore
are more commonly used to indicate generated files, and as such git will overwrite them silently. Entries in .git/info/exclude
are perhaps supposed to be used for local versions of configuration files.
Please read this discussion in its entirety, as there seems to be some confusion as to the difference between the two. I just tried this out, and entries in .git/info/exclude
are protected when you go back in time, producing "error: Untracked working tree file '.rvmrc' would be overwritten by merge." This different behavior between the two might not be deliberate, according to Junio C Hamano. However, if you can remove the entry from .gitignore
and move it to .git/info/exclude
, you might be able to make this work, realizing that the latter is not versioned or shared between repositories and would require manual cooperation with your colleague.
As for the permissions issue, see this:
$ touch foo
$ ls -l foo
-rw-r--r-- 1 josh staff 0 Oct 1 09:55 foo
$ sudo chown root:wheel foo
$ ls -l foo
-rw-r--r-- 1 root wheel 0 Oct 1 09:55 foo
$ unlink foo
$ ls -l foo
ls: foo: No such file or directory
In Unix, the ability to create or remove a file is based only on the permissions of the directory that contains it. Permissions on the file itself are only for modifications to the file (unfortunately in your case). The rm
utility checks permissions on the file as a courtesy, but unlink
is lower-level and blindly calls the system call.