git rm --cached and pull semantics

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?

thanks for your time

list@phuk.ath.cx writes:

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.

On 01/17/2010 12:42 PM, Matthieu Moy wrote:

Thanks for the clarification. I already suspected that this would require extra information to be transmitted. However, wouldn't it make sense for the data model to implement this? As far as I can see, the non-existence of a special placeholder for files being un-added via rm --cached effectively breaks the semantics of that statement. That is, the behaviour on the local tree is inconsistent with the behaviour on trees being pulled. Right now I can't think of a situation where it would be desirable that a local "git rm --cached" is equivalent to a plain "git rm" in the trees being pulled. We do have that differentiation in the UI, so why not implement it consistently? I'd be willing to dig into the code and come up with patches, but only if somebody tells me the overall concept could be acceptable.

But thanks anyway for your attention so far ;-)

The real WTF here is that you are using a workdir as your live dir.

If you treat git as a *source* manager like it is, you'd also have an installer that would copy the resulting files into their live locations, and could be edited to either leave that newly untracked file alone, or deliberately remove it.

Use git as intended, and you get no problems.

On 01/18/2010 01:06 AM, Randal L. Schwartz wrote:

Hm. Good point. I'll try to put that into some post-pull hook and see how it works out. Thanks for the help.