Re: git rm --cached and pull semantics

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Jan 17, 2010, 11:42 UTC
Message-ID: <vpq1vhpufec.fsf@bauges.imag.fr>
In-Reply-To: <4B51EE39.3010401@phuk.ath.cx>

list@phuk.ath.cx writes:

Show 11 quoted lines

> Hello everyone,
>
> I'm trying to manage and distribute a subset of /etc with git.
> Therefore, I have * in .gitignore and use git add -f to add files. Now
> sometimes I want to un-track a file that has been in previous commits,
> but naturally I don't want the file deleted. I just want git to ignore
> it again. As I read it, the way to do that is "git rm --cached $file".
> On the local working tree, that works as expected, but when some remote
> machine pulls a subsequent commit, it deletes the file from its working
> tree. But I just want git to ignore the file again, just as it does in
> the origin repo. How can I do that?

I'd say there's no way, and there will hardly ever be any :-(.

Git is purely snapshot-oriented, which means that when you do a "git rm --cached", the next commit doesn't say "this file has been removed", but instead, it says "the file is not here", which can be interpreted as "the file is not here _anymore_" when comparing the commit and its ancestor.

But as a result, there's no place to store information about _how_ the file was removed. So, for the remote machine doing a "git pull", the merge algorithm just sees that it's not there, and deletes it.

OTOH, after "git pull", it's rather simple to do something like

git show HEAD@{1}:your-file.txt > your-file.txt

to restore it as an untracked file. Maybe it's possible to automate this in a script, but I have no idea how.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/