{"thread":{"id":"26180","subject":"Applying .gitattributes text/eol changes","startedAt":"2011-01-03T17:18:56Z","lastAt":"2011-01-14T09:05:52Z","messageCount":11,"participants":["Marc Strapetz","Michael J Gruber","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"158848","messageId":"4D220500.2000104@syntevo.com","threadId":"26180","inReplyTo":null,"subject":"Applying .gitattributes text/eol changes","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2011-01-03T17:18:56Z","receivedAt":"2011-01-03T17:18:56Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":"I'm looking for an unobtrusive way to apply (committed) changes for\ntext/eol attributes to the working tree. For instance, after having\nchanged \"*.txt eol=crlf\" to \"*.txt eol=lf\", all *.txt files should be\nconverted from CRLF to LF endings. The only advice I found so far is to\nremove .git/index and do a reset --hard. The disadvantage of this\napproach is that every file will be touched:\n\n- although the content does not change, timestamps will be changed. This\nmakes tools like IDEs assume that the file content has been changed.\n(Even if the timestamps would be properly reset, the replacement of the\nfiles would have triggered system file change notifications and I'd\nexpect various tools to still reload these files)\n\n- there will be warnings for files which are locked by other processes\n(at least on Windows). I'm usually seeing this for JAR files which are\nnot affected by eol-attribute changes at all.\n\nOne solution I could think of which might be helpful in other situations\nas well would be to have an \"--unobtrusive\" option for reset which would\nonly replace a file if the content has actually been changed.\n\nMarc.\n"},{"id":"159314","messageId":"4D2C22DE.2040804@syntevo.com","threadId":"26180","inReplyTo":"4D220500.2000104@syntevo.com","subject":"Re: Applying .gitattributes text/eol changes","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2011-01-11T09:29:02Z","receivedAt":"2011-01-11T09:29:02Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":"Any ideas on this?\n\nThanks,\nMarc.\n\n\nOn 03.01.2011 18:18, Marc Strapetz wrote:\n> I'm looking for an unobtrusive way to apply (committed) changes for\n> text/eol attributes to the working tree. For instance, after having\n> changed \"*.txt eol=crlf\" to \"*.txt eol=lf\", all *.txt files should be\n> converted from CRLF to LF endings. The only advice I found so far is to\n> remove .git/index and do a reset --hard. The disadvantage of this\n> approach is that every file will be touched:\n> \n> - although the content does not change, timestamps will be changed. This\n> makes tools like IDEs assume that the file content has been changed.\n> (Even if the timestamps would be properly reset, the replacement of the\n> files would have triggered system file change notifications and I'd\n> expect various tools to still reload these files)\n> \n> - there will be warnings for files which are locked by other processes\n> (at least on Windows). I'm usually seeing this for JAR files which are\n> not affected by eol-attribute changes at all.\n> \n> One solution I could think of which might be helpful in other situations\n> as well would be to have an \"--unobtrusive\" option for reset which would\n> only replace a file if the content has actually been changed.\n> \n> Marc.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n> \n> \n"},{"id":"159321","messageId":"4D2C4902.4010705@drmicha.warpmail.net","threadId":"26180","inReplyTo":"4D220500.2000104@syntevo.com","subject":"Re: Applying .gitattributes text/eol changes","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-01-11T12:11:46Z","receivedAt":"2011-01-11T12:11:46Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:\n> I'm looking for an unobtrusive way to apply (committed) changes for\n> text/eol attributes to the working tree. For instance, after having\n> changed \"*.txt eol=crlf\" to \"*.txt eol=lf\", all *.txt files should be\n> converted from CRLF to LF endings. The only advice I found so far is to\n> remove .git/index and do a reset --hard. The disadvantage of this\n> approach is that every file will be touched:\n> \n> - although the content does not change, timestamps will be changed. This\n\nThe bytewise content does change.\n\n> makes tools like IDEs assume that the file content has been changed.\n\nIt may be that the content is semantically equivalent.\n\n> (Even if the timestamps would be properly reset, the replacement of the\n> files would have triggered system file change notifications and I'd\n> expect various tools to still reload these files)\n> \n> - there will be warnings for files which are locked by other processes\n> (at least on Windows). I'm usually seeing this for JAR files which are\n> not affected by eol-attribute changes at all.\n> \n> One solution I could think of which might be helpful in other situations\n> as well would be to have an \"--unobtrusive\" option for reset which would\n> only replace a file if the content has actually been changed.\n\nHow about\n\ngit ls-files \\*.txt | xargs touch -a\ngit ls-files \\*.txt | git checkout\n\n?\n"},{"id":"159337","messageId":"4D2C62DF.20706@syntevo.com","threadId":"26180","inReplyTo":"4D2C4902.4010705@drmicha.warpmail.net","subject":"Re: Applying .gitattributes text/eol changes","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2011-01-11T14:02:07Z","receivedAt":"2011-01-11T14:02:07Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":"On 11.01.2011 13:11, Michael J Gruber wrote:\n> Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:\n>> I'm looking for an unobtrusive way to apply (committed) changes for\n>> text/eol attributes to the working tree. For instance, after having\n>> changed \"*.txt eol=crlf\" to \"*.txt eol=lf\", all *.txt files should be\n>> converted from CRLF to LF endings. The only advice I found so far is to\n>> remove .git/index and do a reset --hard. The disadvantage of this\n>> approach is that every file will be touched:\n>>\n>> - although the content does not change, timestamps will be changed. This\n> \n> The bytewise content does change.\n\nThe content has only changed for *.txt files, but the timestamps of\n*all* files are updated. I guess (but didn't verify from code), that in\ncase of missing .git/index, Git freshly writes all working tree files,\nignoring already existing files which already have the correct content.\nMaybe this behavior is by intention and makes sense in some cases. In my\ncase it has adverse effects on IDEs and probably other tools which are\nmonitoring the file system.\n\n>> One solution I could think of which might be helpful in other situations\n>> as well would be to have an \"--unobtrusive\" option for reset which would\n>> only replace a file if the content has actually been changed.\n> \n> How about\n> \n> git ls-files \\*.txt | xargs touch -a\n> git ls-files \\*.txt | git checkout\n\nThat won't be helpful as it requires me to know what has changed.\n\n--\nBest regards,\nMarc Strapetz\n=============\nsyntevo GmbH\nhttp://www.syntevo.com\nhttp://blog.syntevo.com\n"},{"id":"159438","messageId":"4D2EFCBD.4020402@drmicha.warpmail.net","threadId":"26180","inReplyTo":"4D2C62DF.20706@syntevo.com","subject":"Re: Applying .gitattributes text/eol changes","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-01-13T13:23:09Z","receivedAt":"2011-01-13T13:23:09Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Marc Strapetz venit, vidit, dixit 11.01.2011 15:02:\n> On 11.01.2011 13:11, Michael J Gruber wrote:\n>> Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:\n>>> I'm looking for an unobtrusive way to apply (committed) changes for\n>>> text/eol attributes to the working tree. For instance, after having\n>>> changed \"*.txt eol=crlf\" to \"*.txt eol=lf\", all *.txt files should be\n>>> converted from CRLF to LF endings. The only advice I found so far is to\n>>> remove .git/index and do a reset --hard. The disadvantage of this\n>>> approach is that every file will be touched:\n>>>\n>>> - although the content does not change, timestamps will be changed. This\n>>\n>> The bytewise content does change.\n> \n> The content has only changed for *.txt files, but the timestamps of\n> *all* files are updated. I guess (but didn't verify from code), that in\n\nWell, sure...\n\n> case of missing .git/index, Git freshly writes all working tree files,\n> ignoring already existing files which already have the correct content.\n> Maybe this behavior is by intention and makes sense in some cases. In my\n> case it has adverse effects on IDEs and probably other tools which are\n> monitoring the file system.\n\n...but changing gitattributes is something you don't do routinely in\nyour workflow; so, at worst there would be an occasional unnecessary run\nof your build process.\n\n> \n>>> One solution I could think of which might be helpful in other situations\n>>> as well would be to have an \"--unobtrusive\" option for reset which would\n>>> only replace a file if the content has actually been changed.\n>>\n>> How about\n>>\n>> git ls-files \\*.txt | xargs touch -a\n>> git ls-files \\*.txt | git checkout\n> \n> That won't be helpful as it requires me to know what has changed.\n\nBut you do know that only (at most) *.txt have changed!\n\nMichael\n"},{"id":"159440","messageId":"4D2F0BF3.2000808@syntevo.com","threadId":"26180","inReplyTo":"4D2EFCBD.4020402@drmicha.warpmail.net","subject":"Re: Applying .gitattributes text/eol changes","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2011-01-13T14:28:03Z","receivedAt":"2011-01-13T14:28:03Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":">> case of missing .git/index, Git freshly writes all working tree files,\n>> ignoring already existing files which already have the correct content.\n>> Maybe this behavior is by intention and makes sense in some cases. In my\n>> case it has adverse effects on IDEs and probably other tools which are\n>> monitoring the file system.\n> \n> ...but changing gitattributes is something you don't do routinely in\n> your workflow; so, at worst there would be an occasional unnecessary run\n> of your build process.\n\nOur Git-SVN bridge does it, potentially on every pull. This is why we\ncurrently need to run \"rm .git/index && git reset --hard\" after every\npull, resp. every checkout (switching to another commit may result in\nchanged .gitattributes as well).\n\nIf a \"git checkout\" would (optionally) make sure that all EOLs are\nproperly set according to .gitattributes, the problem would be resolved.\nAs this might be not so easy to implement, my suggestion was to make\n\"git reset --hard\" work more unobtrusive. I think we can provide a\ncorresponding patch, if it has chances to get accepted.\n\n--\nBest regards,\nMarc Strapetz\n=============\nsyntevo GmbH\nhttp://www.syntevo.com\nhttp://blog.syntevo.com\n\n\n\nOn 13.01.2011 14:23, Michael J Gruber wrote:\n> Marc Strapetz venit, vidit, dixit 11.01.2011 15:02:\n>> On 11.01.2011 13:11, Michael J Gruber wrote:\n>>> Marc Strapetz venit, vidit, dixit 03.01.2011 18:18:\n>>>> I'm looking for an unobtrusive way to apply (committed) changes for\n>>>> text/eol attributes to the working tree. For instance, after having\n>>>> changed \"*.txt eol=crlf\" to \"*.txt eol=lf\", all *.txt files should be\n>>>> converted from CRLF to LF endings. The only advice I found so far is to\n>>>> remove .git/index and do a reset --hard. The disadvantage of this\n>>>> approach is that every file will be touched:\n>>>>\n>>>> - although the content does not change, timestamps will be changed. This\n>>>\n>>> The bytewise content does change.\n>>\n>> The content has only changed for *.txt files, but the timestamps of\n>> *all* files are updated. I guess (but didn't verify from code), that in\n> \n> Well, sure...\n> \n>> case of missing .git/index, Git freshly writes all working tree files,\n>> ignoring already existing files which already have the correct content.\n>> Maybe this behavior is by intention and makes sense in some cases. In my\n>> case it has adverse effects on IDEs and probably other tools which are\n>> monitoring the file system.\n> \n> ...but changing gitattributes is something you don't do routinely in\n> your workflow; so, at worst there would be an occasional unnecessary run\n> of your build process.\n> \n>>\n>>>> One solution I could think of which might be helpful in other situations\n>>>> as well would be to have an \"--unobtrusive\" option for reset which would\n>>>> only replace a file if the content has actually been changed.\n>>>\n>>> How about\n>>>\n>>> git ls-files \\*.txt | xargs touch -a\n>>> git ls-files \\*.txt | git checkout\n>>\n>> That won't be helpful as it requires me to know what has changed.\n> \n> But you do know that only (at most) *.txt have changed!\n> \n> Michael\n> \n> \n"},{"id":"159441","messageId":"4D2F0E3A.8090108@drmicha.warpmail.net","threadId":"26180","inReplyTo":"4D2F0BF3.2000808@syntevo.com","subject":"Re: Applying .gitattributes text/eol changes","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-01-13T14:37:46Z","receivedAt":"2011-01-13T14:37:46Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Marc Strapetz venit, vidit, dixit 13.01.2011 15:28:\n>>> case of missing .git/index, Git freshly writes all working tree files,\n>>> ignoring already existing files which already have the correct content.\n>>> Maybe this behavior is by intention and makes sense in some cases. In my\n>>> case it has adverse effects on IDEs and probably other tools which are\n>>> monitoring the file system.\n>>\n>> ...but changing gitattributes is something you don't do routinely in\n>> your workflow; so, at worst there would be an occasional unnecessary run\n>> of your build process.\n> \n> Our Git-SVN bridge does it, potentially on every pull. This is why we\n> currently need to run \"rm .git/index && git reset --hard\" after every\n> pull, resp. every checkout (switching to another commit may result in\n> changed .gitattributes as well).\n\nOK, now you're telling us what this is about ;)\n\n> If a \"git checkout\" would (optionally) make sure that all EOLs are\n> properly set according to .gitattributes, the problem would be resolved.\n> As this might be not so easy to implement, my suggestion was to make\n> \"git reset --hard\" work more unobtrusive. I think we can provide a\n> corresponding patch, if it has chances to get accepted.\n\nThere have been other cases where git update-index --really-refresh\nwasn't enough. You might want to check whether that is a suitable \"patch\nattack vector\". This might be useful not only for you but also for others.\n\nMichael\n"},{"id":"159442","messageId":"4D2F12EE.4020400@syntevo.com","threadId":"26180","inReplyTo":"4D2F0E3A.8090108@drmicha.warpmail.net","subject":"Re: Applying .gitattributes text/eol changes","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2011-01-13T14:57:50Z","receivedAt":"2011-01-13T14:57:50Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":">> If a \"git checkout\" would (optionally) make sure that all EOLs are\n>> properly set according to .gitattributes, the problem would be resolved.\n>> As this might be not so easy to implement, my suggestion was to make\n>> \"git reset --hard\" work more unobtrusive. I think we can provide a\n>> corresponding patch, if it has chances to get accepted.\n> \n> There have been other cases where git update-index --really-refresh\n> wasn't enough. You might want to check whether that is a suitable \"patch\n> attack vector\". This might be useful not only for you but also for others.\n\nSo your suggestion is to fix \"git update-index --really-refresh\", so\nit's a replacement for \"rm .git/index\"? This sounds reasonable,\nespecially as \"rm .git/index\" is something one feels not comfortable\nabout when performing the first time ;-)\n\nAnyway, I'm still wondering if it will resolve the \"git reset --hard\"\nproblem of re-checking out every file, even if content is already\nidentical in the working tree. I think that part has to be fixed, too.\n\nWhat do you think about \"git checkout --fix-eols\" option as an\nalternative? Its uses cases are more limited, though.\n\n--\nBest regards,\nMarc Strapetz\n=============\nsyntevo GmbH\nhttp://www.syntevo.com\nhttp://blog.syntevo.com\n\n\n\nOn 13.01.2011 15:37, Michael J Gruber wrote:\n> Marc Strapetz venit, vidit, dixit 13.01.2011 15:28:\n>>>> case of missing .git/index, Git freshly writes all working tree files,\n>>>> ignoring already existing files which already have the correct content.\n>>>> Maybe this behavior is by intention and makes sense in some cases. In my\n>>>> case it has adverse effects on IDEs and probably other tools which are\n>>>> monitoring the file system.\n>>>\n>>> ...but changing gitattributes is something you don't do routinely in\n>>> your workflow; so, at worst there would be an occasional unnecessary run\n>>> of your build process.\n>>\n>> Our Git-SVN bridge does it, potentially on every pull. This is why we\n>> currently need to run \"rm .git/index && git reset --hard\" after every\n>> pull, resp. every checkout (switching to another commit may result in\n>> changed .gitattributes as well).\n> \n> OK, now you're telling us what this is about ;)\n> \n>> If a \"git checkout\" would (optionally) make sure that all EOLs are\n>> properly set according to .gitattributes, the problem would be resolved.\n>> As this might be not so easy to implement, my suggestion was to make\n>> \"git reset --hard\" work more unobtrusive. I think we can provide a\n>> corresponding patch, if it has chances to get accepted.\n> \n> There have been other cases where git update-index --really-refresh\n> wasn't enough. You might want to check whether that is a suitable \"patch\n> attack vector\". This might be useful not only for you but also for others.\n> \n> Michael\n> \n> \n"},{"id":"159454","messageId":"7vd3o01iw9.fsf@alter.siamese.dyndns.org","threadId":"26180","inReplyTo":"4D2F12EE.4020400@syntevo.com","subject":"Re: Applying .gitattributes text/eol changes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-01-13T23:30:30Z","receivedAt":"2011-01-13T23:30:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marc Strapetz <marc.strapetz@syntevo.com> writes:\n\n> So your suggestion is to fix \"git update-index --really-refresh\", so\n\nThe option is about telling git: \"Earlier I promised I wouldn't touch\nthese paths by setting their assume-unchanged bit, but I touched them.\nPlease refresh the cached stat information in the index, ignoring the\npromise I didn't keep.\"\n\nI do not think it is a good idea to conflate your \"Everything is suspect\nbecause smudge filter has changed; please recompute all\" request into the\nsame option.  People who use assume-unchanged would probably want \"Please\nrescan because I changed smudge filter\" request to be carried out while\nstill honoring the assume-unchanged bit they set earlier.\n\n> Anyway, I'm still wondering if it will resolve the \"git reset --hard\"\n> problem of re-checking out every file, even if content is already\n> identical in the working tree. I think that part has to be fixed, too.\n\nThere is not much to fix there. If you removed the index, then there is no\ninformation to tell you that \"content is already identical\" unless you\nactually check things out and compare.  By the time you found it out, you\nalready have done the checkout.\n\nIOW, the current code does:\n\n\topen object\n        read from the object\n        deflate and write to the destination file\n\nwhile your \"fix\" needs to look like this:\n\n\topen object\n        read from the object\n        deflate and write to a temporary file\n        open the existing file\n        read from the file and compare it to the temporary we just wrote\n        if same, delete, otherwise rename the temporary file.\n\njust for the rare case where there is an untracked file that the user is\nwilling to overwrite (we are discussing \"rm .git/index && reset --hard\"\nhere) happens to have the same contents.  Not a good enough reason to add\nunwelcome complexity to the codepath.\n\n> What do you think about \"git checkout --fix-eols\" option as an\n> alternative? Its uses cases are more limited, though.\n\nWhat does it do?  \"git checkout --fix-eols $path\" will overwrite $path\nwith the data at $path in the index?  Perhaps you can use the \"-f\" option.\n\nAdding an option to \"checkout\" might be better than update-index from the\nUI point of view, but the issue is not just \"eols\".  \"eol\" is a mere\nspecial case of smudge filter that controls how the contents from the\nrepository are modified before getting written out to the working tree.\n"},{"id":"159465","messageId":"4D3009D3.3050403@drmicha.warpmail.net","threadId":"26180","inReplyTo":"7vd3o01iw9.fsf@alter.siamese.dyndns.org","subject":"Re: Applying .gitattributes text/eol changes","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-01-14T08:31:15Z","receivedAt":"2011-01-14T08:31:15Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 14.01.2011 00:30:\n> Marc Strapetz <marc.strapetz@syntevo.com> writes:\n> \n>> So your suggestion is to fix \"git update-index --really-refresh\", so\n> \n> The option is about telling git: \"Earlier I promised I wouldn't touch\n> these paths by setting their assume-unchanged bit, but I touched them.\n> Please refresh the cached stat information in the index, ignoring the\n> promise I didn't keep.\"\n> \n> I do not think it is a good idea to conflate your \"Everything is suspect\n> because smudge filter has changed; please recompute all\" request into the\n> same option.  People who use assume-unchanged would probably want \"Please\n> rescan because I changed smudge filter\" request to be carried out while\n> still honoring the assume-unchanged bit they set earlier.\n\nWhat I meant was to introduce a new option --refresh-stat or something.\nWe have solved the \"stale stat info problem\" (changed dev nums after\nreboot) in a different way meanwhile, but I think there was a different\ncase (can't come up with the thread right now) where something like this\ncould have helped.\n\n> \n>> Anyway, I'm still wondering if it will resolve the \"git reset --hard\"\n>> problem of re-checking out every file, even if content is already\n>> identical in the working tree. I think that part has to be fixed, too.\n> \n> There is not much to fix there. If you removed the index, then there is no\n> information to tell you that \"content is already identical\" unless you\n> actually check things out and compare.  By the time you found it out, you\n> already have done the checkout.\n> \n> IOW, the current code does:\n> \n> \topen object\n>         read from the object\n>         deflate and write to the destination file\n> \n> while your \"fix\" needs to look like this:\n> \n> \topen object\n>         read from the object\n>         deflate and write to a temporary file\n>         open the existing file\n>         read from the file and compare it to the temporary we just wrote\n>         if same, delete, otherwise rename the temporary file.\n> \n> just for the rare case where there is an untracked file that the user is\n> willing to overwrite (we are discussing \"rm .git/index && reset --hard\"\n> here) happens to have the same contents.  Not a good enough reason to add\n> unwelcome complexity to the codepath.\n> \n>> What do you think about \"git checkout --fix-eols\" option as an\n>> alternative? Its uses cases are more limited, though.\n> \n> What does it do?  \"git checkout --fix-eols $path\" will overwrite $path\n> with the data at $path in the index?  Perhaps you can use the \"-f\" option.\n> \n> Adding an option to \"checkout\" might be better than update-index from the\n> UI point of view, but the issue is not just \"eols\".  \"eol\" is a mere\n> special case of smudge filter that controls how the contents from the\n> repository are modified before getting written out to the working tree.\n\nExactly, this is a more general issue. The typical answer to these\nissues is that you change attributes and filters only occasionally, so\nthe cost of a rm .git/index && git reset --hard is irrelevant. But still\nthere should be a less scary way of (really) refreshing the index. Also\nnote that the cost of the command itself is only a part of the picture -\nin the OP's case (which is a bit convoluted, of course) \"cost\" is really\ncommand execution + the cost of the consequences (rebuilding triggered\nby unnecessary touches). For the typical use cases, the existing options\nand command paths do the perfectly sane and efficient thing.\n\nMichael\n"},{"id":"159469","messageId":"4D3011F0.5040900@syntevo.com","threadId":"26180","inReplyTo":"7vd3o01iw9.fsf@alter.siamese.dyndns.org","subject":"Re: Applying .gitattributes text/eol changes","fromName":"Marc Strapetz","fromEmail":"marc.strapetz@syntevo.com","sentAt":"2011-01-14T09:05:52Z","receivedAt":"2011-01-14T09:05:52Z","isPatch":false,"sender":{"key":"marc.strapetz@syntevo.com","avatar":"https://avatars.githubusercontent.com/u/3380730?v=4"},"body":">> What do you think about \"git checkout --fix-eols\" option as an\n>> alternative? Its uses cases are more limited, though.\n> \n> What does it do?  \"git checkout --fix-eols $path\" will overwrite $path\n> with the data at $path in the index?  Perhaps you can use the \"-f\" option.\n> \n> Adding an option to \"checkout\" might be better than update-index from the\n> UI point of view, but the issue is not just \"eols\".  \"eol\" is a mere\n> special case of smudge filter that controls how the contents from the\n> repository are modified before getting written out to the working tree.\n\nSo there could be a \"--thoroughly\" option which will skip the stat check\n(checkout_entry) and instead perform the procedure already outlined for\nrebase:\n\n> \topen object\n>         read from the object\n>         deflate and write to a temporary file\n>         open the existing file\n>         read from the file and compare it to the temporary we just wrote\n>         if same, delete, otherwise rename the temporary file.\n\nAFAIU, this change will effect mainly checkout struct, checkout_entry\nand write_entry. write_entry already deals with temporary files, so that\nshouldn't be too complex!?\n\n--\nBest regards,\nMarc Strapetz\n=============\nsyntevo GmbH\nhttp://www.syntevo.com\nhttp://blog.syntevo.com\n\n\n\n\nOn 14.01.2011 00:30, Junio C Hamano wrote:\n> Marc Strapetz <marc.strapetz@syntevo.com> writes:\n> \n>> So your suggestion is to fix \"git update-index --really-refresh\", so\n> \n> The option is about telling git: \"Earlier I promised I wouldn't touch\n> these paths by setting their assume-unchanged bit, but I touched them.\n> Please refresh the cached stat information in the index, ignoring the\n> promise I didn't keep.\"\n> \n> I do not think it is a good idea to conflate your \"Everything is suspect\n> because smudge filter has changed; please recompute all\" request into the\n> same option.  People who use assume-unchanged would probably want \"Please\n> rescan because I changed smudge filter\" request to be carried out while\n> still honoring the assume-unchanged bit they set earlier.\n> \n>> Anyway, I'm still wondering if it will resolve the \"git reset --hard\"\n>> problem of re-checking out every file, even if content is already\n>> identical in the working tree. I think that part has to be fixed, too.\n> \n> There is not much to fix there. If you removed the index, then there is no\n> information to tell you that \"content is already identical\" unless you\n> actually check things out and compare.  By the time you found it out, you\n> already have done the checkout.\n> \n> IOW, the current code does:\n> \n> \topen object\n>         read from the object\n>         deflate and write to the destination file\n> \n> while your \"fix\" needs to look like this:\n> \n> \topen object\n>         read from the object\n>         deflate and write to a temporary file\n>         open the existing file\n>         read from the file and compare it to the temporary we just wrote\n>         if same, delete, otherwise rename the temporary file.\n> \n> just for the rare case where there is an untracked file that the user is\n> willing to overwrite (we are discussing \"rm .git/index && reset --hard\"\n> here) happens to have the same contents.  Not a good enough reason to add\n> unwelcome complexity to the codepath.\n> \n>> What do you think about \"git checkout --fix-eols\" option as an\n>> alternative? Its uses cases are more limited, though.\n> \n> What does it do?  \"git checkout --fix-eols $path\" will overwrite $path\n> with the data at $path in the index?  Perhaps you can use the \"-f\" option.\n> \n> Adding an option to \"checkout\" might be better than update-index from the\n> UI point of view, but the issue is not just \"eols\".  \"eol\" is a mere\n> special case of smudge filter that controls how the contents from the\n> repository are modified before getting written out to the working tree.\n> \n> \n> \n> \n"}]}