{"thread":{"id":"57768","subject":"Bug Report","startedAt":"2022-04-20T19:45:38Z","lastAt":"2022-04-21T17:53:20Z","messageCount":6,"participants":["Daniel Habenicht","brian m. carlson","rsbecker@nexbridge.com","Torsten Bögershausen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"453998","messageId":"f1647260b37d492d96ac92f8ef30a087AS1P190MB1750B08CC923A45E2C959250ECF59@AS1P190MB1750.EURP190.PROD.OUTLOOK.COM","threadId":"57768","inReplyTo":null,"subject":"Bug Report","fromName":"Daniel Habenicht","fromEmail":"daniel-habenicht@outlook.de","sentAt":"2022-04-20T19:45:32Z","receivedAt":"2022-04-20T19:45:38Z","isPatch":false,"sender":{"key":"daniel-habenicht@outlook.de","avatar":null},"body":"Hi there,\n\nI think I found a bug or at least some unexpected behavior. \nPlease have a look at the following reproduction repo: \n\nhttps://github.com/DanielHabenicht/bug-reproduction.git-repo/blob/main/README.md\n\n\n\n[System Info]\ngit version:\ngit version 2.33.1.windows.1\ncpu: x86_64\nbuilt from commit: 05d80adb775077d673fab685009ede4a1003ed92\nsizeof-long: 4\nsizeof-size_t: 8\nshell-path: /bin/sh\nfeature: fsmonitor--daemon\nuname: Windows 10.0 19042 \ncompiler info: gnuc: 10.3\nlibc info: no libc information available\n$SHELL (typically, interactive shell): \n\n\n[Enabled Hooks]\nNone\n\nAlso reproduced on: \n[System Info] \ngit version:\ngit version 2.35.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 5.4.0-1074-azure #77~18.04.1-Ubuntu SMP Wed Mar 30 15:36:02 UTC 2022 x86_64\ncompiler info: gnuc: 9.4\nlibc info: glibc: 2.31\n$SHELL (typically, interactive shell): /bin/bash\n\n\nCheers,\nDaniel\n"},{"id":"454036","messageId":"YmB7gvfKY/0njjZy@camp.crustytoothpaste.net","threadId":"57768","inReplyTo":"f1647260b37d492d96ac92f8ef30a087AS1P190MB1750B08CC923A45E2C959250ECF59@AS1P190MB1750.EURP190.PROD.OUTLOOK.COM","subject":"Re: Bug Report","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2022-04-20T21:30:42Z","receivedAt":"2022-04-20T21:30:48Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:\n> Hi there,\n> \n> I think I found a bug or at least some unexpected behavior. \n> Please have a look at the following reproduction repo: \n> \n> https://github.com/DanielHabenicht/bug-reproduction.git-repo/blob/main/README.md\n\nYou're more likely to get someone to look at this if you post the actual\ntext to the list. While I might be willing to look at it on GitHub,\nother folks won't, and I probably won't get a chance to look at this\nissue anytime soon.\n-- \nbrian m. carlson (he/him or they/them)\nToronto, Ontario, CA\n"},{"id":"454039","messageId":"017001d85506$bee0adf0$3ca209d0$@nexbridge.com","threadId":"57768","inReplyTo":"YmB7gvfKY/0njjZy@camp.crustytoothpaste.net","subject":"RE: Bug Report","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2022-04-20T22:34:00Z","receivedAt":"2022-04-20T22:34:17Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On April 20, 2022 5:31 PM, brian m. carlson wrote:\n>On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:\n>> Hi there,\n>>\n>> I think I found a bug or at least some unexpected behavior. Please\n>> have a look at the following reproduction repo:\n>>\n>> https://github.com/DanielHabenicht/bug-reproduction.git-repo/blob/main\n>> /README.md\n>\n>You're more likely to get someone to look at this if you post the actual text to the\n>list. While I might be willing to look at it on GitHub, other folks won't, and I\n>probably won't get a chance to look at this issue anytime soon.\n\nThe only thing that I can see that is apparently a problem is that autocrlf=false is not documented in the config help, so it is not apparent what the expected result should be relative to the test case. That could be considered confusing. There could also be confusion relative to when the git diff was done relative to what is in the staging area given his test case. I think what Daniel may really want is to use autocrlf=input.\n\nDaniel, please post your entire report to this list rather than using GitHub, links, or attachments. I happened to be on GitHub at that moment, so looked, but otherwise, I would not have specifically looked.\n\n--Randall\n\n--\nBrief whoami: NonStop&UNIX developer since approximately\nUNIX(421664400)\nNonStop(211288444200000000)\n-- In real life, I talk too much.\n\n"},{"id":"454070","messageId":"AS1P190MB1750C249B4857371132C5DF0ECF49@AS1P190MB1750.EURP190.PROD.OUTLOOK.COM","threadId":"57768","inReplyTo":"017001d85506$bee0adf0$3ca209d0$@nexbridge.com","subject":"Re: Bug Report","fromName":"Daniel Habenicht","fromEmail":"daniel-habenicht@outlook.de","sentAt":"2022-04-21T13:20:37Z","receivedAt":"2022-04-21T13:20:44Z","isPatch":false,"sender":{"key":"daniel-habenicht@outlook.de","avatar":null},"body":"Hi Randall and Brian, \n\nthanks for the fast response. \n@Randall: I also tried it with autocrlf=input and it still reproduces. I included it in the reproduction. I also added more examples for confusing behaviour. \n\n\nHere is the full bug report: \n(You can view a Markdown rendered version of this reproduction at: https://github.com/DanielHabenicht/bug-reproduction.git-repo)\n\n# Description \n\nWhen changing the `.gitattributes` file not all changes to the checked in files are apparent.\nThey only get updated on a new clone or when refreshing the index - that's somehow expected. \nBut it creates confusion and unexpected behavior if they are not updated together with the `.gitattributes` changes. \nIt can make easy changes between branches impossible, break the flow of squashing commits or lead to confusing state of everlasting uncommited change.\nThese edge cases for confusing behaviour I have added below. \n\n# Reproduction \n\n1. Checkout with the following `.gitconfig` settings set:\n\n```gitconfig\n# .gitconfig\n[core]\n autocrlf = false\n# Or\n autocrlf = input\n```\n\n2. Clone the repository\n```bash\ngit clone https://github.com/DanielHabenicht/bug-reproduction.git-repo.git\n```\n\n3. `test.cs` should be shown as `modified`\n\n> This is confusing to the user, he just checked the repo out and did not change a thing. At least there should be a warning?\n \n```\ngit status\nOn branch main\nYour branch is up to date with 'origin/main'.\n\nChanges not staged for commit:\n (use \"git add ...\" to update what will be committed)\n (use \"git restore ...\" to discard changes in working directory)\n modified: test.cs\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n```\n\n5. Running any git command like the ones below will not remove the changed file:\n\n```bash\ngit rm --cached -r .\ngit reset --hard\ngit add --renormalize .\n```\n\n> This as well is very confusing and there is no indication on why this is happening and there are still modified files after everything should be reset. \n> Keep in mind that this could have happened in error and could be happening to a totally unrelated (to the inital `.gitattributes` change) user. \n\n6. Running `git diff` is even more confusing, and doing as the warning suggests (`warning: CRLF will be replaced by LF in test.cs. The file will have its original line endings in your working directory`) and replacing `CRLF` by `LF` does silence the warning but does not change the diff itself:\n\n```diff\nwarning: CRLF will be replaced by LF in test.cs.\nThe file will have its original line endings in your working directory\ndiff --git b/test.cs a/test.cs\nindex 1e230ed..5464a2d 100644\n--- b/test.cs\n+++ a/test.cs\n@@ -1,11 +1,11 @@\n-using System.Diagnostics.CodeAnalysis;\n-using System.Linq;\n-using Xunit;\n-using Moq;\n-\n-\n-\n-namespace Tests\n-{\n-\n-}\n+using System.Diagnostics.CodeAnalysis;^M\n+using System.Linq;^M\n+using Xunit;^M\n+using Moq;^M\n+^M\n+^M\n+^M\n+namespace Tests^M\n+{^M\n+^M\n+}^M\n```\n\n> This is showing the exact opposite of what git is really doing. Actually it replaces the line encoding of the index (i/crlf) with the right encoding (i/lf) (see **[1]**)\n> From the git user perspective everything is in great shape, the file is LF, as it should be, but still git complains about a change that is not visible to the user without background knowledge about gitattributes and the git index. \n\n8. Try changing the branch to a modified copy with `git checkout some-changes` is not possible (also with the recommended command). The only solution would be to commit - nothing else helps (but thats not really a solution). : \n\n```bash\nerror: Your local changes to the following files would be overwritten by checkout:\n test.cs\nPlease commit your changes or stash them before you switch branches.\nAborting\n```\n\n> This makes changing branches harder, as it can't be force reset and git will always complain about files being overwritten.\n> It also break the flow for squashing commits as you would need to manually intervene (and add a commit) if someone forgot to commit all files after a .gitattributes change and only recognized it at a later date.\n\n\n**[1]**: I hope this answer explained it right to me: https://stackoverflow.com/a/71937898/9277073. \nBut it is rather unintuitive to me, and possibly other users, as there seems to be a hidden middle layer leading to this problem. See the graph at the github repo)\n\n\n\nCheers,\nDaniel\n\n\n\n\nDaniel Habenicht\n\n\nFrom: rsbecker@nexbridge.com \nSent: Thursday, April 21, 2022 00:34\nTo: 'brian m. carlson' ; 'Daniel Habenicht' \nCc: git@vger.kernel.org \nSubject: RE: Bug Report \n \nOn April 20, 2022 5:31 PM, brian m. carlson wrote:\n>On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:\n>> Hi there,\n>>\n>> I think I found a bug or at least some unexpected behavior. Please\n>> have a look at the following reproduction repo:\n>>\n>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDanielHabenicht%2Fbug-reproduction.git-repo%2Fblob%2Fmain&data=05%7C01%7C%7C145ae6f595d54ac7b5fd08da231de43c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637860908535410706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HXFm4sBZ5yQGQPkBlkzKhkgDJOXBqSlgETkrhGxgkmI%3D&reserved=0\n>> /README.md\n>\n>You're more likely to get someone to look at this if you post the actual text to the\n>list.  While I might be willing to look at it on GitHub, other folks won't, and I\n>probably won't get a chance to look at this issue anytime soon.\n\nThe only thing that I can see that is apparently a problem is that autocrlf=false is not documented in the config help, so it is not apparent what the expected result should be relative to the test case. That could be considered confusing. There could also be confusion relative to when the git diff was done relative to what is in the staging area given his test case. I think what Daniel may really want is to use autocrlf=input.\n\nDaniel, please post your entire report to this list rather than using GitHub, links, or attachments. I happened to be on GitHub at that moment, so looked, but otherwise, I would not have specifically looked.\n\n--Randall\n\n--\nBrief whoami: NonStop&UNIX developer since approximately\nUNIX(421664400)\nNonStop(211288444200000000)\n-- In real life, I talk too much.\n"},{"id":"454079","messageId":"20220421143931.o53dm2qnfcpsido7@tb-raspi4","threadId":"57768","inReplyTo":"AS1P190MB1750C249B4857371132C5DF0ECF49@AS1P190MB1750.EURP190.PROD.OUTLOOK.COM","subject":"Re: Bug Report","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2022-04-21T14:39:31Z","receivedAt":"2022-04-21T14:40:11Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"\nHej Daniel,\n\n $ git clone https://github.com/DanielHabenicht/bug-reproduction.git-repo.git\n $ cd bug-reproduction.git-repo.git\n $ git ls-files --eol\n i/none w/none attr/ .gitattributes\n i/lf w/lf attr/ README.md\n i/crlf w/crlf attr/text eol=lf test.cs\n\nYour repo needs to be re-normalized:\n $ git add --renormalize .\n $ git status\n On branch main\n Your branch is up to date with 'origin/main'.\n\nChanges to be committed:\n (use \"git restore --staged ...\" to unstage)\n modified: test.cs\n\nThat is all that needs to be done.\n\nUsers which are confused may put their frustration aside,\nand read the documentation:\n\nhttps://git-scm.com/docs/gitattributes\n\nespecially the part about the line endings and normalization,\nsearch for \"renormalize\".\n\nI don't know, if there is something we can do that makes live easier,\nbut if yes: suggestions are more than welcome.\n\nSo yes, thanks for the report.\n\n\n\n\nOn Thu, Apr 21, 2022 at 01:20:37PM +0000, Daniel Habenicht wrote:\n> Hi Randall and Brian, \n>\n> thanks for the fast response.\n> @Randall: I also tried it with autocrlf=input and it still reproduces. I included it in the reproduction. I also added more examples for confusing behaviour.\n>\n>\n> Here is the full bug report: \n> (You can view a Markdown rendered version of this reproduction at: https://github.com/DanielHabenicht/bug-reproduction.git-repo)\n>\n> # Description\n>\n> When changing the `.gitattributes` file not all changes to the checked in files are apparent.\n> They only get updated on a new clone or when refreshing the index - that's somehow expected.\n> But it creates confusion and unexpected behavior if they are not updated together with the `.gitattributes` changes.\n> It can make easy changes between branches impossible, break the flow of squashing commits or lead to confusing state of everlasting uncommited change.\n> These edge cases for confusing behaviour I have added below.\n>\n> # Reproduction\n>\n> 1. Checkout with the following `.gitconfig` settings set:\n>\n> ```gitconfig\n> # .gitconfig\n> [core]\n> autocrlf = false\n> # Or\n> autocrlf = input\n> ```\n>\n> 2. Clone the repository\n> ```bash\n> git clone https://github.com/DanielHabenicht/bug-reproduction.git-repo.git\n> ```\n>\n> 3. `test.cs` should be shown as `modified`\n>\n> > This is confusing to the user, he just checked the repo out and did not change a thing. At least there should be a warning?\n>\n> ```\n> git status\n> On branch main\n> Your branch is up to date with 'origin/main'.\n>\n> Changes not staged for commit:\n> (use \"git add ...\" to update what will be committed)\n> (use \"git restore ...\" to discard changes in working directory)\n> modified: test.cs\n>\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> ```\n>\n> 5. Running any git command like the ones below will not remove the changed file:\n>\n> ```bash\n> git rm --cached -r .\n> git reset --hard\n> git add --renormalize .\n> ```\n>\n> > This as well is very confusing and there is no indication on why this is happening and there are still modified files after everything should be reset.\n> > Keep in mind that this could have happened in error and could be happening to a totally unrelated (to the inital `.gitattributes` change) user.\n>\n> 6. Running `git diff` is even more confusing, and doing as the warning suggests (`warning: CRLF will be replaced by LF in test.cs. The file will have its original line endings in your working directory`) and replacing `CRLF` by `LF` does silence the warning but does not change the diff itself:\n>\n> ```diff\n> warning: CRLF will be replaced by LF in test.cs.\n> The file will have its original line endings in your working directory\n> diff --git b/test.cs a/test.cs\n> index 1e230ed..5464a2d 100644\n> --- b/test.cs\n> +++ a/test.cs\n> @@ -1,11 +1,11 @@\n> -using System.Diagnostics.CodeAnalysis;\n> -using System.Linq;\n> -using Xunit;\n> -using Moq;\n> -\n> -\n> -\n> -namespace Tests\n> -{\n> -\n> -}\n> +using System.Diagnostics.CodeAnalysis;^M\n> +using System.Linq;^M\n> +using Xunit;^M\n> +using Moq;^M\n> +^M\n> +^M\n> +^M\n> +namespace Tests^M\n> +{^M\n> +^M\n> +}^M\n> ```\n>\n> > This is showing the exact opposite of what git is really doing. Actually it replaces the line encoding of the index (i/crlf) with the right encoding (i/lf) (see **[1]**)\n> > From the git user perspective everything is in great shape, the file is LF, as it should be, but still git complains about a change that is not visible to the user without background knowledge about gitattributes and the git index.\n>\n> 8. Try changing the branch to a modified copy with `git checkout some-changes` is not possible (also with the recommended command). The only solution would be to commit - nothing else helps (but thats not really a solution). :\n>\n> ```bash\n> error: Your local changes to the following files would be overwritten by checkout:\n> test.cs\n> Please commit your changes or stash them before you switch branches.\n> Aborting\n> ```\n>\n> > This makes changing branches harder, as it can't be force reset and git will always complain about files being overwritten.\n> > It also break the flow for squashing commits as you would need to manually intervene (and add a commit) if someone forgot to commit all files after a .gitattributes change and only recognized it at a later date.\n>\n>\n> **[1]**: I hope this answer explained it right to me: https://stackoverflow.com/a/71937898/9277073.\n> But it is rather unintuitive to me, and possibly other users, as there seems to be a hidden middle layer leading to this problem. See the graph at the github repo)\n>\n>\n>\n> Cheers,\n> Daniel\n>\n>\n>\n>\n> Daniel Habenicht\n>\n>\n> From: rsbecker@nexbridge.com \n> Sent: Thursday, April 21, 2022 00:34\n> To: 'brian m. carlson' ; 'Daniel Habenicht' \n> Cc: git@vger.kernel.org \n> Subject: RE: Bug Report\n>  \n> On April 20, 2022 5:31 PM, brian m. carlson wrote:\n> >On 2022-04-20 at 19:45:32, Daniel Habenicht wrote:\n> >> Hi there,\n> >>\n> >> I think I found a bug or at least some unexpected behavior. Please\n> >> have a look at the following reproduction repo:\n> >>\n> >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDanielHabenicht%2Fbug-reproduction.git-repo%2Fblob%2Fmain&data=05%7C01%7C%7C145ae6f595d54ac7b5fd08da231de43c%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637860908535410706%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=HXFm4sBZ5yQGQPkBlkzKhkgDJOXBqSlgETkrhGxgkmI%3D&reserved=0\n> >> /README.md\n> >\n> >You're more likely to get someone to look at this if you post the actual text to the\n> >list.  While I might be willing to look at it on GitHub, other folks won't, and I\n> >probably won't get a chance to look at this issue anytime soon.\n>\n> The only thing that I can see that is apparently a problem is that autocrlf=false is not documented in the config help, so it is not apparent what the expected result should be relative to the test case. That could be considered confusing. There could also be confusion relative to when the git diff was done relative to what is in the staging area given his test case. I think what Daniel may really want is to use autocrlf=input.\n>\n> Daniel, please post your entire report to this list rather than using GitHub, links, or attachments. I happened to be on GitHub at that moment, so looked, but otherwise, I would not have specifically looked.\n>\n> --Randall\n>\n> --\n> Brief whoami: NonStop&UNIX developer since approximately\n> UNIX(421664400)\n> NonStop(211288444200000000)\n> -- In real life, I talk too much.\n"},{"id":"454096","messageId":"20220421175254.54y7dzxhtu33wu6w@tb-raspi4","threadId":"57768","inReplyTo":"AS1P190MB175022A7F1264807ECA464A8ECF49@AS1P190MB1750.EURP190.PROD.OUTLOOK.COM","subject":"Re: Bug Report","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2022-04-21T17:52:54Z","receivedAt":"2022-04-21T17:53:20Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Thu, Apr 21, 2022 at 03:29:20PM +0000, Daniel Habenicht wrote:\n> Hi Torsten,\n>\n> thanks for your answer.\n> As I explained in the reproduction, I now know why this is happening and I successfully resolved it for my repository.\n> I just wanted raise awareness that it is not self-explanatory to non-professional users.\n>\n> I would suggest two changes:\n>\n> 1. Warn the user on commit of the .gitattributes that he also needs to renormalize the repository (or even better, do that by default).\n> 2. Include the information about the need for a renormalization commit on checkouts/restores/reset if there are still files not updated (shown as modified).\n>\n> Regarding the \"Users which are confused may put their frustration aside and read the documentation\".\n> I think most users won't make the connection for the first 3 google searches, if the problem arises only several commits after the gitattributes change, or if the repository gets cloned by a new user.\n>\n>\n> Cheers,\n> Daniel\n>\n\n(Sorry for the top-posting before, this list uses bottom-posting)\n\nI still hope that users who are able to find the feature of the\n.gitattributes file(s) are able to find out about the renormalaztion as well.\nAnd you are not the first one who runs into this problem, if that is of any\ncomfort.\n\nNow, back to your suggestions:\nThe way Git works does not seam to allow a reliable detection of files\nthat are \"modified\" after a checkout/restore/reset when .gitattributes\nchange. (Someone may correct me if this is wrong.\nIt is related/connected to the timestamps of \"the index\"\nand the files in the working tree and the fact that \"git add\" will\nneed to store a new version of the file in the repo e.g CRLF -> LF)\n\nAutomatically doing a renormalization seems to be an impossible thing:\nThe commit as such is atomic, including all files in the working tree\nwith their line endings and the .gitattributes file itself.\nChanging things here seems the wrong way to go, at least for me.\n\nShowing a hint when a .gitattributes file is commited may be more feasable.\nI haven't digged which part of the code would be the best place.\n\nPatches and ideas are welcome\n"}]}