{"thread":{"id":"36394","subject":"wrong handling of text git attribute leading to files incorrectly reported as modified","startedAt":"2014-04-11T20:20:47Z","lastAt":"2014-04-16T17:03:29Z","messageCount":8,"participants":["Frank Ammeter","Torsten Bögershausen","Brandon McCaig","Junio C Hamano","Holger Hellmuth"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"238742","messageId":"E8A9F28E-FF68-4899-B02C-DB7A2C66F38A@ammeter.ch","threadId":"36394","inReplyTo":null,"subject":"wrong handling of text git attribute leading to files incorrectly reported as modified","fromName":"Frank Ammeter","fromEmail":"git@ammeter.ch","sentAt":"2014-04-11T20:20:47Z","receivedAt":"2014-04-11T20:20:47Z","isPatch":false,"sender":{"key":"git@ammeter.ch","avatar":null},"body":"I’m not a git expert and this might be the wrong place to ask this question,\nso please send me somewhere else if I’m in the wrong place.\n\nI asked the same question on stack overflow, but didn’t get any response:\nhttp://stackoverflow.com/questions/22823004/files-incorrectly-reported-modified-git-attributes-buggy-leading-to-inconsist\n\nIf a file is committed with crlf line endings with the text attribute unset in the working tree, but the text attribute is set in the repo, the file will be incorrectly shown as modified - for all users checking out the file.\nResetting or manually modifying the file will not help - The only remedy is to commit the .gitattributes with the text attribute set for the file.\n\nWouldn’t it be better to only consider the checked-in gitattributes instead of the attributes in the working tree?\nIs this a bug in git handling gitattributes or is this wrong usage? If it is wrong usage, is it documented anywhere?\n\nThe following shell script demonstrates the problem:\n\n#!/bin/bash\n# creating a git repo \"repo\"\nrm -rf repo\nmkdir repo\ncd repo\ngit init\n# committing gitattributes with text attribute set for all files\necho \"* text\" > .gitattributes\ngit add .gitattributes\ngit commit -m \"added .gitattributes\"\n# add a file with CRLF line ending with text attribute unset\necho -e \"crlf\\r\" > crlffile\necho \"* -text\" > .gitattributes\ngit add crlffile\ngit commit -m \"added crlffile\"\ngit checkout .gitattributes\n# now \"crlffile\" shows as modified, even though it isn't.\n# only way to resolve is to modify .gitattributes \ngit status crlffile\n# crlffile shown as modified.\ngit checkout crlffile\ngit status crlffile\n# crlffile shown as modified.\ngit reset --hard\ngit status\n# crlffile shown as modified.\n# git diff will report the CR as the difference\ngit diff \n# but external diff reports no differences.\ngit difftool --extcmd=diff --no-prompt\n\nThanks for your help\nFrank Ammeter"},{"id":"238744","messageId":"534852D4.5070608@web.de","threadId":"36394","inReplyTo":"E8A9F28E-FF68-4899-B02C-DB7A2C66F38A@ammeter.ch","subject":"Re: wrong handling of text git attribute leading to files incorrectly reported as modified","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2014-04-11T20:38:44Z","receivedAt":"2014-04-11T20:38:44Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2014-04-11 22.20, Frank Ammeter wrote:\n> I’m not a git expert and this might be the wrong place to ask this question,\n> so please send me somewhere else if I’m in the wrong place.\n> \n> I asked the same question on stack overflow, but didn’t get any response:\n> http://stackoverflow.com/questions/22823004/files-incorrectly-reported-modified-git-attributes-buggy-leading-to-inconsist\n> \n> If a file is committed with crlf line endings with the text attribute unset in the working tree, but the text attribute is set in the repo, the file will be incorrectly shown as modified - for all users checking out the file.\n> Resetting or manually modifying the file will not help - The only remedy is to commit the .gitattributes with the text attribute set for the file.\n> \n> Wouldn’t it be better to only consider the checked-in gitattributes instead of the attributes in the working tree?\nNo.\nIf you change stuff in your working tree (and .gitattributes is a part of the working tree)\nhow should Git know what you want?\nThe primary assumption is that you know what you are doing in the working tree.\n> Is this a bug in git handling gitattributes or is this wrong usage? \nI thinkk No, yes.\n\nIf it is wrong usage, is it documented anywhere?\nPlease have a look here:\nhttps://www.kernel.org/pub/software/scm/git/docs/gitattributes.html\n\n\nAnd if you think that the documentation can be improved,\nplease feel free to send suggestions.\n\nA simple \"git diff\" is a good start, and a patch with a commit message is even better.\n"},{"id":"238768","messageId":"D552B854-59FB-406A-8CDE-3A1269CD0F6E@ammeter.ch","threadId":"36394","inReplyTo":"534852D4.5070608@web.de","subject":"Re: wrong handling of text git attribute leading to files incorrectly reported as modified","fromName":"Frank Ammeter","fromEmail":"git@ammeter.ch","sentAt":"2014-04-12T11:29:35Z","receivedAt":"2014-04-12T11:29:35Z","isPatch":false,"sender":{"key":"git@ammeter.ch","avatar":null},"body":"\nAm 11.04.2014 um 22:38 schrieb Torsten Bögershausen :\n\n> On 2014-04-11 22.20, Frank Ammeter wrote:\n>> I’m not a git expert and this might be the wrong place to ask this question,\n>> so please send me somewhere else if I’m in the wrong place.\n>> \n>> I asked the same question on stack overflow, but didn’t get any response:\n>> http://stackoverflow.com/questions/22823004/files-incorrectly-reported-modified-git-attributes-buggy-leading-to-inconsist\n>> \n>> If a file is committed with crlf line endings with the text attribute unset in the working tree, but the text attribute is set in the repo, the file will be incorrectly shown as modified - for all users checking out the file.\n>> Resetting or manually modifying the file will not help - The only remedy is to commit the .gitattributes with the text attribute set for the file.\n>> \n>> Wouldn’t it be better to only consider the checked-in gitattributes instead of the attributes in the working tree?\n> No.\n> If you change stuff in your working tree (and .gitattributes is a part of the working tree)\n> how should Git know what you want?\nI don’t see that argument.\nI don’t know why at the time of a commit git should read unstaged files from my working tree - that affect my commit.\n\n> The primary assumption is that you know what you are doing in the working tree.\n>> Is this a bug in git handling gitattributes or is this wrong usage? \n> I thinkk No, yes.\n> \n> If it is wrong usage, is it documented anywhere?\n> Please have a look here:\n> https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html\nI’ve read this, can’t see anything about my problem in this document.\nNo offense, but because I don’t understand the reasoning behind this, I can’t really help improve the documentation.\nI don’t think it makes much sense if I as a non-git-developer add something like \n„please apologize the git developers didn’t really think far enough when they invented git attributes, because they don't care if your repo gets inconsistent…\" \n"},{"id":"238897","messageId":"CANUGeEYoS+t57jfpEoZE-2u_cD1uOD5pdp=yF--Rhpb9z91qxQ@mail.gmail.com","threadId":"36394","inReplyTo":"D552B854-59FB-406A-8CDE-3A1269CD0F6E@ammeter.ch","subject":"Re: wrong handling of text git attribute leading to files incorrectly reported as modified","fromName":"Brandon McCaig","fromEmail":"bamccaig@gmail.com","sentAt":"2014-04-15T20:12:50Z","receivedAt":"2014-04-15T20:12:50Z","isPatch":false,"sender":{"key":"bamccaig@gmail.com","avatar":"https://gravatar.com/avatar/05b01f2b62a5ddbaa1946579266a8d9e970fed0c0b3c20e8d42aca973c31531c?d=mp&s=160"},"body":"Frank:\n\nOn Sat, Apr 12, 2014 at 7:29 AM, Frank Ammeter wrote:\n> I don’t see that argument.\n> I don’t know why at the time of a commit git should read unstaged files from my working tree - that affect my commit.\n\n.gitignore works the exact same way. If you modify .gitignore then git\nstatus will immediately reflect those changes. You don't even have to\nstore either file in the repository (.gitignore or .gitattributes).\nThat is for your benefit, and for easily sharing that configuration\nwith collaborators. Git only cares that the file exists in your\nworking tree at run-time.\n\nRegards,\n\n\n-- \nBrandon McCaig \nCastopulence Software \nBlog \nperl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.\nq{Vg qbrfa'\\''g nyjnlf fbhaq gung jnl.};\ntr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'\n"},{"id":"238903","messageId":"xmqqob02jnhk.fsf@gitster.dls.corp.google.com","threadId":"36394","inReplyTo":"CANUGeEYoS+t57jfpEoZE-2u_cD1uOD5pdp=yF--Rhpb9z91qxQ@mail.gmail.com","subject":"Re: wrong handling of text git attribute leading to files incorrectly reported as modified","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-15T21:23:35Z","receivedAt":"2014-04-15T21:23:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon McCaig writes:\n\n> That is for your benefit, and for easily sharing that configuration\n> with collaborators. Git only cares that the file exists in your\n> working tree at run-time.\n\nIt is a lot more than \"for sharing\". If you made .gitignore only\neffective after it gets committed, you cannot test your updated\nversion of .gitignore is correct before committing the change.\n"},{"id":"238931","messageId":"B3DF4E4A-F740-4588-AFD5-74D99E5299F5@ammeter.ch","threadId":"36394","inReplyTo":"xmqqob02jnhk.fsf@gitster.dls.corp.google.com","subject":"Re: wrong handling of text git attribute leading to files incorrectly reported as modified","fromName":"Frank Ammeter","fromEmail":"git@ammeter.ch","sentAt":"2014-04-16T11:49:02Z","receivedAt":"2014-04-16T11:49:02Z","isPatch":false,"sender":{"key":"git@ammeter.ch","avatar":null},"body":"Am 15.04.2014 um 23:23 schrieb Junio C Hamano :\n\n> Brandon McCaig writes:\n> \n>> That is for your benefit, and for easily sharing that configuration\n>> with collaborators. Git only cares that the file exists in your\n>> working tree at run-time.\n> \n> It is a lot more than \"for sharing\". If you made .gitignore only\n> effective after it gets committed, you cannot test your updated\n> version of .gitignore is correct before committing the change.\n\nOk, I can follow that logic for .gitignore, but I was talking about .gitattributes and I always thought that .gitattributes as belonging to the repository, since it affects a) how files are checked out and b) how they are stored inside the repository.\nIf committing .gitattributes were only for sharing convenience, git couldn’t decide whether to convert line endings when checking out a file. The same behavior doesn’t apply to .gitignore, because git will checkout a file that was added even though it matches an ignore pattern in .gitignore.\n"},{"id":"238943","messageId":"xmqqob01i5h0.fsf@gitster.dls.corp.google.com","threadId":"36394","inReplyTo":"B3DF4E4A-F740-4588-AFD5-74D99E5299F5@ammeter.ch","subject":"Re: wrong handling of text git attribute leading to files incorrectly reported as modified","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-16T16:50:19Z","receivedAt":"2014-04-16T16:50:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Frank Ammeter writes:\n\n> Am 15.04.2014 um 23:23 schrieb Junio C Hamano :\n>\n>> Brandon McCaig writes:\n>> \n>>> That is for your benefit, and for easily sharing that configuration\n>>> with collaborators. Git only cares that the file exists in your\n>>> working tree at run-time.\n>> \n>> It is a lot more than \"for sharing\". If you made .gitignore only\n>> effective after it gets committed, you cannot test your updated\n>> version of .gitignore is correct before committing the change.\n>\n> Ok, I can follow that logic for .gitignore, but I was talking about .gitattributes...\n\nThey are conceptually the same thing, so if you can follow the logic\nfor .gitignore, you already can follow the logic for .gitattributes.\n\nThe only two readons we have a separate .gitignore are because other\nSCMs had a similar mechanism, and because it came before attributes.\nIf we didn't have these two constraints, it would have made a lot\nmore sense to express \"this path is to be ignored\" by setting\n\"ignored\" attribute.\n"},{"id":"238945","messageId":"534EB7E1.7060807@ira.uka.de","threadId":"36394","inReplyTo":"E8A9F28E-FF68-4899-B02C-DB7A2C66F38A@ammeter.ch","subject":"Re: wrong handling of text git attribute leading to files incorrectly reported as modified","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2014-04-16T17:03:29Z","receivedAt":"2014-04-16T17:03:29Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 11.04.2014 22:20, schrieb Frank Ammeter:\n> #!/bin/bash\n> # creating a git repo \"repo\"\n> rm -rf repo\n> mkdir repo\n> cd repo\n> git init\n> # committing gitattributes with text attribute set for all files\n> echo \"* text\" > .gitattributes\n> git add .gitattributes\n> git commit -m \"added .gitattributes\"\n> # add a file with CRLF line ending with text attribute unset\n> echo -e \"crlf\\r\" > crlffile\n> echo \"* -text\" > .gitattributes\n> git add crlffile\n> git commit -m \"added crlffile\"\n> git checkout .gitattributes\n> # now \"crlffile\" shows as modified, even though it isn't.\n\nIt is. In the repository is stored a crlffile with \\r in it which would \nbe changed when you would do a commit (with your current gitattributes)\n\n> # only way to resolve is to modify .gitattributes\n\nNo. This works too:\n\ngit add crlffile\ngit commit -m . # practically removes the \\r inside the repository\ngit status crlffile\n#shows up clean\n"}]}