git rm --cached and pull semantics

git rm --cached and pull semantics

[list]

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

Re: git rm --cached and pull semantics

[Matthieu Moy]

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/

Re: git rm --cached and pull semantics

[list]

On 01/17/2010 12:42 PM, Matthieu Moy wrote:
> 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 ;-)

Re: git rm --cached and pull semantics

[Randal L. Schwartz]

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.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: git rm --cached and pull semantics

[list]

On 01/18/2010 01:06 AM, Randal L. Schwartz wrote:
> 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.
>
>   
Hm. Good point. I'll try to put that into some post-pull hook and see
how it works out. Thanks for the help.