Re: git rm --cached and pull semantics

From: list@phuk.ath.cx <list@phuk.ath.cx>
Date: Jan 17, 2010, 22:50 UTC
Message-ID: <4B53941A.6020500@phuk.ath.cx>
In-Reply-To: <vpq1vhpufec.fsf@bauges.imag.fr>

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

Show 33 quoted lines

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

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 ;-)