{"thread":{"id":"22245","subject":"git rm --cached and pull semantics","startedAt":"2010-01-16T16:50:01Z","lastAt":"2010-01-18T02:31:27Z","messageCount":5,"participants":["list@phuk.ath.cx","Matthieu Moy","Randal L. Schwartz"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"131885","messageId":"4B51EE39.3010401@phuk.ath.cx","threadId":"22245","inReplyTo":null,"subject":"git rm --cached and pull semantics","fromName":"","fromEmail":"list@phuk.ath.cx","sentAt":"2010-01-16T16:50:01Z","receivedAt":"2010-01-16T16:50:01Z","isPatch":false,"sender":{"key":"list@phuk.ath.cx","avatar":null},"body":"Hello everyone,\n\nI'm trying to manage and distribute a subset of /etc with git.\nTherefore, I have * in .gitignore and use git add -f to add files. Now\nsometimes I want to un-track a file that has been in previous commits,\nbut naturally I don't want the file deleted. I just want git to ignore\nit again. As I read it, the way to do that is \"git rm --cached $file\".\nOn the local working tree, that works as expected, but when some remote\nmachine pulls a subsequent commit, it deletes the file from its working\ntree. But I just want git to ignore the file again, just as it does in\nthe origin repo. How can I do that?\n\nthanks for your time\n"},{"id":"131940","messageId":"vpq1vhpufec.fsf@bauges.imag.fr","threadId":"22245","inReplyTo":"4B51EE39.3010401@phuk.ath.cx","subject":"Re: git rm --cached and pull semantics","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-01-17T11:42:03Z","receivedAt":"2010-01-17T11:42:03Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"list@phuk.ath.cx writes:\n\n> Hello everyone,\n>\n> I'm trying to manage and distribute a subset of /etc with git.\n> Therefore, I have * in .gitignore and use git add -f to add files. Now\n> sometimes I want to un-track a file that has been in previous commits,\n> but naturally I don't want the file deleted. I just want git to ignore\n> it again. As I read it, the way to do that is \"git rm --cached $file\".\n> On the local working tree, that works as expected, but when some remote\n> machine pulls a subsequent commit, it deletes the file from its working\n> tree. But I just want git to ignore the file again, just as it does in\n> the origin repo. How can I do that?\n\nI'd say there's no way, and there will hardly ever be any :-(.\n\nGit is purely snapshot-oriented, which means that when you do a \"git\nrm --cached\", the next commit doesn't say \"this file has been\nremoved\", but instead, it says \"the file is not here\", which can be\ninterpreted as \"the file is not here _anymore_\" when comparing the\ncommit and its ancestor.\n\nBut as a result, there's no place to store information about _how_ the\nfile was removed. So, for the remote machine doing a \"git pull\", the\nmerge algorithm just sees that it's not there, and deletes it.\n\nOTOH, after \"git pull\", it's rather simple to do something like\n\ngit show HEAD@{1}:your-file.txt > your-file.txt\n\nto restore it as an untracked file. Maybe it's possible to automate\nthis in a script, but I have no idea how.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"131994","messageId":"4B53941A.6020500@phuk.ath.cx","threadId":"22245","inReplyTo":"vpq1vhpufec.fsf@bauges.imag.fr","subject":"Re: git rm --cached and pull semantics","fromName":"","fromEmail":"list@phuk.ath.cx","sentAt":"2010-01-17T22:50:02Z","receivedAt":"2010-01-17T22:50:02Z","isPatch":false,"sender":{"key":"list@phuk.ath.cx","avatar":null},"body":"On 01/17/2010 12:42 PM, Matthieu Moy wrote:\n> list@phuk.ath.cx writes:\n>\n>> Hello everyone,\n>>\n>> I'm trying to manage and distribute a subset of /etc with git.\n>> Therefore, I have * in .gitignore and use git add -f to add files. Now\n>> sometimes I want to un-track a file that has been in previous commits,\n>> but naturally I don't want the file deleted. I just want git to ignore\n>> it again. As I read it, the way to do that is \"git rm --cached $file\".\n>> On the local working tree, that works as expected, but when some remote\n>> machine pulls a subsequent commit, it deletes the file from its working\n>> tree. But I just want git to ignore the file again, just as it does in\n>> the origin repo. How can I do that?\n>\n> I'd say there's no way, and there will hardly ever be any :-(.\n>\n> Git is purely snapshot-oriented, which means that when you do a \"git\n> rm --cached\", the next commit doesn't say \"this file has been\n> removed\", but instead, it says \"the file is not here\", which can be\n> interpreted as \"the file is not here _anymore_\" when comparing the\n> commit and its ancestor.\n>\n> But as a result, there's no place to store information about _how_ the\n> file was removed. So, for the remote machine doing a \"git pull\", the\n> merge algorithm just sees that it's not there, and deletes it.\n>\n> OTOH, after \"git pull\", it's rather simple to do something like\n>\n> git show HEAD@{1}:your-file.txt > your-file.txt\n>\n> to restore it as an untracked file. Maybe it's possible to automate\n> this in a script, but I have no idea how.\n>\nThanks for the clarification. I already suspected that this would\nrequire extra information to be transmitted. However, wouldn't it make\nsense for the data model to implement this? As far as I can see, the\nnon-existence of a special placeholder for files being un-added via rm\n--cached effectively breaks the semantics of that statement. That is,\nthe behaviour on the local tree is inconsistent with the behaviour on\ntrees being pulled. Right now I can't think of a situation where it\nwould be desirable that a local \"git rm --cached\" is equivalent to a\nplain \"git rm\" in the trees being pulled. We do have that\ndifferentiation in the UI, so why not implement it consistently?\nI'd be willing to dig into the code and come up with patches, but only\nif somebody tells me the overall concept could be acceptable.\n\nBut thanks anyway for your attention so far ;-)\n"},{"id":"131996","messageId":"86my0c5l9s.fsf@blue.stonehenge.com","threadId":"22245","inReplyTo":"4B53941A.6020500@phuk.ath.cx","subject":"Re: git rm --cached and pull semantics","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2010-01-18T00:06:39Z","receivedAt":"2010-01-18T00:06:39Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":"\nThe real WTF here is that you are using a workdir as your live dir.\n\nIf you treat git as a *source* manager like it is, you'd also have an\ninstaller that would copy the resulting files into their live locations,\nand could be edited to either leave that newly untracked file alone,\nor deliberately remove it.\n\nUse git as intended, and you get no problems.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion\n"},{"id":"132005","messageId":"4B53C7FF.7060604@phuk.ath.cx","threadId":"22245","inReplyTo":"86my0c5l9s.fsf@blue.stonehenge.com","subject":"Re: git rm --cached and pull semantics","fromName":"","fromEmail":"list@phuk.ath.cx","sentAt":"2010-01-18T02:31:27Z","receivedAt":"2010-01-18T02:31:27Z","isPatch":false,"sender":{"key":"list@phuk.ath.cx","avatar":null},"body":"On 01/18/2010 01:06 AM, Randal L. Schwartz wrote:\n> The real WTF here is that you are using a workdir as your live dir.\n>\n> If you treat git as a *source* manager like it is, you'd also have an\n> installer that would copy the resulting files into their live locations,\n> and could be edited to either leave that newly untracked file alone,\n> or deliberately remove it.\n>\n> Use git as intended, and you get no problems.\n>\n> \nHm. Good point. I'll try to put that into some post-pull hook and see\nhow it works out. Thanks for the help.\n"}]}