{"thread":{"id":"55528","subject":"Problems with CRLF line endings","startedAt":"2021-04-20T16:33:51Z","lastAt":"2021-04-20T23:34:53Z","messageCount":2,"participants":["Dennis Worthem","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"422450","messageId":"DM6PR17MB2106CEAA1CED29E738B81602F9489@DM6PR17MB2106.namprd17.prod.outlook.com","threadId":"55528","inReplyTo":null,"subject":"Problems with CRLF line endings","fromName":"Dennis Worthem","fromEmail":"dennis.worthem@amtrustgroup.com","sentAt":"2021-04-20T16:33:40Z","receivedAt":"2021-04-20T16:33:51Z","isPatch":false,"sender":{"key":"dennis.worthem@amtrustgroup.com","avatar":null},"body":"We as a multi-developer team are using git version 2.31.0.windows.1 on the developer side which we use through Git Bash on Windows 10. On the server side we use Azure Dev Ops.\nApproximate 20 developers are working from one repository.  We want all files to use CRLF line endings with working with the files. All the developers have a .bashrc file with contents of \"git config --global core.autocrlf true\".\nAdditionally, the repository with a .gitattributes file with contents:\n*.raml text eol=crlf\n*.json text eol=crlf\n*.vb text eol=crlf\n*.cs text eol=crlf\n*.vbproj text eol=crlf\n*.csproj text eol=crlf\nThe problem we are having is that when pulling branches from the repository we still have recurring  files with phantom changes.\nWe have told developer who experience this to either reset the indices cache and do a hard reset or renormalize and check in and push as indicated in a number of web sites. But it still seems to be happening.\nOur repository has a release branch and a develop branch and the problems seems to be happening with mainly develop which has more developer traffic.\n\nIt seems inconsistent on changes, The file will download with all CRLF endings but the file is marked as modified and it is not clear what has changed.\n\nDoes anyone have recommendations on how we can get this to work (always CRLF) without the phantom changes occurring in an apparently non-deterministic manner? Have I configured this completely?\n\nThe problem may be that one or more developers have not updated their local indices. Also would it help to have everyone do a one-time reclone the repository?\n\nOne file marked as modified has\n$ git ls-files --eol | grep WCAPI.Core/WCAPI.Core.csproj\ni/crlf  w/crlf  attr/text eol=crlf      WCAPI.Core/WCAPI.Core.csproj\n\nand a similar one not marked as modified has\n\n$ git ls-files --eol | grep WCAPI/WCAPI.csproj\ni/lf    w/crlf  attr/text eol=crlf      WCAPI/WCAPI.csproj\n\nWhy does the modified one have 'i/crlf' and the unmodified ones have 'i/lf'\n\nAny help would be appreciated.\n\n\n"},{"id":"422502","messageId":"YH9lFnJYpejqTOhk@camp.crustytoothpaste.net","threadId":"55528","inReplyTo":"DM6PR17MB2106CEAA1CED29E738B81602F9489@DM6PR17MB2106.namprd17.prod.outlook.com","subject":"Re: Problems with CRLF line endings","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-04-20T23:34:46Z","receivedAt":"2021-04-20T23:34:53Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-04-20 at 16:33:40, Dennis Worthem wrote:\n> We as a multi-developer team are using git version 2.31.0.windows.1 on the developer side which we use through Git Bash on Windows 10. On the server side we use Azure Dev Ops.\n> Approximate 20 developers are working from one repository.  We want all files to use CRLF line endings with working with the files. All the developers have a .bashrc file with contents of \"git config --global core.autocrlf true\".\n> Additionally, the repository with a .gitattributes file with contents:\n> *.raml text eol=crlf\n> *.json text eol=crlf\n> *.vb text eol=crlf\n> *.cs text eol=crlf\n> *.vbproj text eol=crlf\n> *.csproj text eol=crlf\n\ntext eol=crlf tells Git to store LF endings in the repository and use\nCRLF endings in the working tree.  This is the recommended way to\nconfigure things, since it means that operations like diffs don't show\ntrailing whitespace.\n\n> The problem we are having is that when pulling branches from the repository we still have recurring  files with phantom changes.\n> We have told developer who experience this to either reset the indices cache and do a hard reset or renormalize and check in and push as indicated in a number of web sites. But it still seems to be happening.\n> Our repository has a release branch and a develop branch and the problems seems to be happening with mainly develop which has more developer traffic.\n> \n> It seems inconsistent on changes, The file will download with all CRLF endings but the file is marked as modified and it is not clear what has changed.\n\nThis happens when the file that's checked into the repository hasn't\nbeen properly checked in and either a filter (e.g., Git LFS), a line\nending change, or a working tree encoding causes the file as checked out\nto differ when checked into the index.\n\nFor example, since you've told Git to store LF line endings in the\nindex, if the file is checked into the repository with CRLF endings but\nthen it gets updated, Git will re-read and convert the file into LF\nendings in the index, and it will appear modified.  That can happen\nbecause the timestamp changes or for other reasons that make Git think\nit's dirty.\n\nThe proper solution to this is to do \"git add --renormalize .\" and then\ncommit.  You may want to also set up your CI such that CRLF line endings\nin the repository cause a hard failure.  For example, you may wish to do\nthis:\n\n----\n#!/bin/sh\n\nif git ls-files --eol | grep i/crlf\nthen\n    echo \"The above files have CRLF line endings in the index.  Aborting.\" >&2\n    false\nfi\n----\n\nIt's unclear to me why this is happening if you have the above\nconfigured, but it could be files which have not been updated and still\ncontain the old CRLF line endings in the repository, which the\nrenormalize should fix.  It's also possible someone is using a different\nGit implementation, possibly one integrated in their editor, and it\ndoesn't honor the .gitattributes file.  Or someone could have a\n.git/info/attributes that's set to override the value.\n\nBy adding a hard fail on this in your CI system, you'll figure out where\nthe source of the problem is very quickly.  Most of the projects I'm on\nhave hard failures on trailing whitespace, and this is very effective in\nstopping it from reappearing in the codebase.\n\n> Does anyone have recommendations on how we can get this to work (always CRLF) without the phantom changes occurring in an apparently non-deterministic manner? Have I configured this completely?\n\nIt's unclear to me why this happens inconsistently, but it seems to\nmostly affect Windows users.  Users of other OSes don't seem to have\nfiles in the working tree re-cleaned unexpectedly as often.  That's why\nthis appears to be nondeterministic; I'm not sure what it is about\nWindows that seems to cause this problem to show up more often there.\n\n> The problem may be that one or more developers have not updated their local indices. Also would it help to have everyone do a one-time reclone the repository?\n> \n> One file marked as modified has\n> $ git ls-files --eol | grep WCAPI.Core/WCAPI.Core.csproj\n> i/crlf  w/crlf  attr/text eol=crlf      WCAPI.Core/WCAPI.Core.csproj\n\nThis says that the index has CRLF line endings.  That's not correct.\n\n> and a similar one not marked as modified has\n> \n> $ git ls-files --eol | grep WCAPI/WCAPI.csproj\n> i/lf    w/crlf  attr/text eol=crlf      WCAPI/WCAPI.csproj\n\nThis is correct.\n\n> Why does the modified one have 'i/crlf' and the unmodified ones have 'i/lf'\n\nBecause it was originally checked in that way and hasn't been fixed.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"}]}