Re: git rm --cached and pull semantics

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

list@phuk.ath.cx writes:

> 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/