{"thread":{"id":"50038","subject":"Bug in lineendings handling that prevents resetting checking out, rebasing etc","startedAt":"2018-12-14T21:04:55Z","lastAt":"2018-12-15T20:59:28Z","messageCount":7,"participants":["Mr&Mrs D","John Passaro","Torsten Bögershausen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"365371","messageId":"CABRG_PEy9H7za9cTdXMvFB37GfDvpBvsDDoLZ5-Bpm=9NWzLiw@mail.gmail.com","threadId":"50038","inReplyTo":null,"subject":"Bug in lineendings handling that prevents resetting checking out, rebasing etc","fromName":"Mr&Mrs D","fromEmail":"the.ubik@gmail.com","sentAt":"2018-12-14T21:04:15Z","receivedAt":"2018-12-14T21:04:55Z","isPatch":false,"sender":{"key":"the.ubik@gmail.com","avatar":"https://gravatar.com/avatar/1d625f1bf89affc956dae8519e1b65ed5d970523db6170104cbee0c3162a17e4?d=mp&s=160"},"body":"Hi all,\n\nI maintain a python project you can clone from:\n\ngit@github.com:wrye-bash/wrye-bash.git\n\nFor reasons unknown git sees a particular file as changed\n(Mopy/Docs/Bash Readme Template.html, sometimes others too). This file\nwas probably committed to the svn repository this git repo was created\nfrom with CRLF line endings. When we moved to git we added a\ngitattributes file (\nhttps://github.com/wrye-bash/wrye-bash/blob/dev/.gitattributes ) and\nthis file was edited to explicitly state htms are text - all to no\navail. From time to time - on windows - as in when checking out an old\ncommit - git would see that file as changed. The only workaround that\nworked for me was\n\n    git rm -r . --cached -q && git reset --hard\n\nFor more details and discussion see this SO question I posted almost\nfive years ago:\n\nhttps://stackoverflow.com/questions/21122094/git-line-endings-cant-stash-reset-and-now-cant-rebase-over-spurious-line-en\n\nI used to work in windows and the bug was tolerable as there was that\nworkaround. Now I moved to mac and no workaround works anymore - we\nhave a special page on our wiki  with workarounds for this one btw:\n\nhttps://github.com/wrye-bash/wrye-bash/wiki/%5Bgit%5D-Issues-with-line-endings-preventing-checking,-merge,-etc\n\nWell after 5 years and countless hours trying to solve this I reach\nout to you guys and girls - _this is a full-time bug in git line\nendings handling_. When someone issues a git reset --hard this should\nwork no matter what - well it does not. So this bug may be really a\ncan of worms.\n\nPlease someone clone this repo on linux or mac - probably just cloning\nwill have the files appear as changed (by the way hitting refresh on\ngit gui I have different sets of files appear as changed). If not then\n\ngit checkout utumno-wip\ngit rebase -i dev\n\nand then select a commit to edit should be enough to trigger this bug\n\nNeedless to say I am  well aware of things like `git add --renormalize\n.` - but renormalizing is not the issue. The issue is that _files show\nas changed and even a git reset --hard won't convince git that\nnothing's changed_.\n\n$ git reset --hard\nHEAD is now at e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n$ git status\ninteractive rebase in progress; onto 02ae6f26\nLast commands done (4 commands done):\n   pick 3a39a0c0 Monkey patch for undecodable inis:\n   pick e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n  (see more in file .git/rebase-merge/done)\nNext commands to do (19 remaining commands):\n   edit a3a7b237 Amend last commit and linefixes:  ΕΕΕΕ\n   edit 432fd314 fFF handle empty or malformed inis\n  (use \"git rebase --edit-todo\" to view and edit)\nYou are currently editing a commit while rebasing branch 'utumno-wip'\non '02ae6f26'.\n  (use \"git commit --amend\" to amend the current commit)\n  (use \"git rebase --continue\" once you are satisfied with your changes)\n\nChanges not staged for commit:\n  (use \"git add <file>...\" to update what will be committed)\n  (use \"git checkout -- <file>...\" to discard changes in working directory)\n\nmodified:   Mopy/Docs/Bash Readme Template.html\n\nUntracked files:\n  (use \"git add <file>...\" to include in what will be committed)\n\n.DS_Store\n.idea.7z\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n$\n\nI really hope someone here can debug this\nThanks!\n"},{"id":"365379","messageId":"CAJdN7KitOpH=WFJW2SgU8mt75pFzF2mhD0TrCkyfnYugRdTkxw@mail.gmail.com","threadId":"50038","inReplyTo":"CABRG_PEy9H7za9cTdXMvFB37GfDvpBvsDDoLZ5-Bpm=9NWzLiw@mail.gmail.com","subject":"Re: Bug in lineendings handling that prevents resetting checking out, rebasing etc","fromName":"John Passaro","fromEmail":"john.a.passaro@gmail.com","sentAt":"2018-12-14T21:21:46Z","receivedAt":"2018-12-14T21:22:30Z","isPatch":false,"sender":{"key":"john.a.passaro@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6754005?v=4"},"body":"On Fri, Dec 14, 2018 at 4:08 PM Mr&Mrs D <the.ubik@gmail.com> wrote:\n>\n> Hi all,\n>\n> I maintain a python project you can clone from:\n>\n> git@github.com:wrye-bash/wrye-bash.git\n>\n> For reasons unknown git sees a particular file as changed\n> (Mopy/Docs/Bash Readme Template.html, sometimes others too). This file\n> was probably committed to the svn repository this git repo was created\n> from with CRLF line endings. When we moved to git we added a\n> gitattributes file (\n> https://github.com/wrye-bash/wrye-bash/blob/dev/.gitattributes ) and\n> this file was edited to explicitly state htms are text - all to no\n> avail. From time to time - on windows - as in when checking out an old\n> commit - git would see that file as changed. The only workaround that\n> worked for me was\n>\n>     git rm -r . --cached -q && git reset --hard\n>\n> For more details and discussion see this SO question I posted almost\n> five years ago:\n>\n> https://stackoverflow.com/questions/21122094/git-line-endings-cant-stash-reset-and-now-cant-rebase-over-spurious-line-en\n>\n> I used to work in windows and the bug was tolerable as there was that\n> workaround. Now I moved to mac and no workaround works anymore - we\n> have a special page on our wiki  with workarounds for this one btw:\n>\n> https://github.com/wrye-bash/wrye-bash/wiki/%5Bgit%5D-Issues-with-line-endings-preventing-checking,-merge,-etc\n>\n> Well after 5 years and countless hours trying to solve this I reach\n> out to you guys and girls - _this is a full-time bug in git line\n> endings handling_. When someone issues a git reset --hard this should\n> work no matter what - well it does not. So this bug may be really a\n> can of worms.\n>\n> Please someone clone this repo on linux or mac - probably just cloning\n> will have the files appear as changed (by the way hitting refresh on\n> git gui I have different sets of files appear as changed). If not then\n>\n> git checkout utumno-wip\n> git rebase -i dev\n>\n> and then select a commit to edit should be enough to trigger this bug\n\nDoes not reproduce on git 2.20.0 (mac high sierra fwiw). What version of git\nare you using?\n>\n> Needless to say I am  well aware of things like `git add --renormalize\n> .` - but renormalizing is not the issue. The issue is that _files show\n> as changed and even a git reset --hard won't convince git that\n> nothing's changed_.\n>\n> $ git reset --hard\n> HEAD is now at e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n> $ git status\n> interactive rebase in progress; onto 02ae6f26\n> Last commands done (4 commands done):\n>    pick 3a39a0c0 Monkey patch for undecodable inis:\n>    pick e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n>   (see more in file .git/rebase-merge/done)\n> Next commands to do (19 remaining commands):\n>    edit a3a7b237 Amend last commit and linefixes:  ΕΕΕΕ\n>    edit 432fd314 fFF handle empty or malformed inis\n>   (use \"git rebase --edit-todo\" to view and edit)\n> You are currently editing a commit while rebasing branch 'utumno-wip'\n> on '02ae6f26'.\n>   (use \"git commit --amend\" to amend the current commit)\n>   (use \"git rebase --continue\" once you are satisfied with your changes)\n>\n> Changes not staged for commit:\n>   (use \"git add <file>...\" to update what will be committed)\n>   (use \"git checkout -- <file>...\" to discard changes in working directory)\n>\n> modified:   Mopy/Docs/Bash Readme Template.html\n>\n> Untracked files:\n>   (use \"git add <file>...\" to include in what will be committed)\n>\n> .DS_Store\n> .idea.7z\n>\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> $\n>\n> I really hope someone here can debug this\n> Thanks!\n"},{"id":"365381","messageId":"20181214213246.GA2182@tor.lan","threadId":"50038","inReplyTo":"CABRG_PEy9H7za9cTdXMvFB37GfDvpBvsDDoLZ5-Bpm=9NWzLiw@mail.gmail.com","subject":"Re: Bug in lineendings handling that prevents resetting checking out, rebasing etc","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2018-12-14T21:32:46Z","receivedAt":"2018-12-14T21:32:51Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Fri, Dec 14, 2018 at 04:04:15PM -0500, Mr&Mrs D wrote:\n> Hi all,\n> \n> I maintain a python project you can clone from:\n> \n> git@github.com:wrye-bash/wrye-bash.git\n> \n> For reasons unknown git sees a particular file as changed\n> (Mopy/Docs/Bash Readme Template.html, sometimes others too). This file\n> was probably committed to the svn repository this git repo was created\n> from with CRLF line endings. When we moved to git we added a\n> gitattributes file (\n> https://github.com/wrye-bash/wrye-bash/blob/dev/.gitattributes ) and\n> this file was edited to explicitly state htms are text - all to no\n> avail. From time to time - on windows - as in when checking out an old\n> commit - git would see that file as changed. The only workaround that\n> worked for me was\n> \n>     git rm -r . --cached -q && git reset --hard\n> \n> For more details and discussion see this SO question I posted almost\n> five years ago:\n> \n> https://stackoverflow.com/questions/21122094/git-line-endings-cant-stash-reset-and-now-cant-rebase-over-spurious-line-en\n> \n> I used to work in windows and the bug was tolerable as there was that\n> workaround. Now I moved to mac and no workaround works anymore - we\n> have a special page on our wiki  with workarounds for this one btw:\n> \n> https://github.com/wrye-bash/wrye-bash/wiki/%5Bgit%5D-Issues-with-line-endings-preventing-checking,-merge,-etc\n> \n> Well after 5 years and countless hours trying to solve this I reach\n> out to you guys and girls - _this is a full-time bug in git line\n> endings handling_. When someone issues a git reset --hard this should\n> work no matter what - well it does not. So this bug may be really a\n> can of worms.\n> \n> Please someone clone this repo on linux or mac - probably just cloning\n> will have the files appear as changed (by the way hitting refresh on\n> git gui I have different sets of files appear as changed). If not then\n> \n> git checkout utumno-wip\nThet commit is -excuse me if that sounds too harsh- is messed up.\ngit status says\nmodified:   Mopy/Docs/Bash Readme Template.html\n\nAnd if I dig into the EOL stuff, I run\ngit ls-files --eol | grep  Readme | less\n\nAnd find a contradiction here:\ni/crlf  w/crlf  attr/text               Mopy/Docs/Bash Readme Template.html\n\nThe attributes say \"text\" and the file has CRLF \"in the repo\",\n(techically speaking in the index) and that is an \"illegal\" condition\nin the repo, and not a bug in Git.\nI didn't try the rebase as such, sice the first problem needs\nto be fixed, before we try to move on.\n\nSo, the old commits are problematic/illegal and they are as they are.\nSuch a commit can not be fixed, whenever somebody checks it out,\nthere will be a problem (or two, or none, depending on the timing,\nthe file system...)\n\nWe can not fix commits like b1acc012878c9fdd8b4ad610ce7eae0dcbcbcab0.\nWe can make new commits, and fix them.\n\nWe can fix one branch, and other branches, and merge them together.\nBut rebase seems to be problamatic, at least to me.\nWhat exactly do you want to do?\n\nCan we agree to do a merge of 2 branches?\nThen I can possibly help you out.\n\n\n\n\n\n> git rebase -i dev\n> \n> and then select a commit to edit should be enough to trigger this bug\n> \n> Needless to say I am  well aware of things like `git add --renormalize\n> .` - but renormalizing is not the issue. The issue is that _files show\n> as changed and even a git reset --hard won't convince git that\n> nothing's changed_.\n> \n> $ git reset --hard\n> HEAD is now at e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n> $ git status\n> interactive rebase in progress; onto 02ae6f26\n> Last commands done (4 commands done):\n>    pick 3a39a0c0 Monkey patch for undecodable inis:\n>    pick e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n>   (see more in file .git/rebase-merge/done)\n> Next commands to do (19 remaining commands):\n>    edit a3a7b237 Amend last commit and linefixes:  ΕΕΕΕ\n>    edit 432fd314 fFF handle empty or malformed inis\n>   (use \"git rebase --edit-todo\" to view and edit)\n> You are currently editing a commit while rebasing branch 'utumno-wip'\n> on '02ae6f26'.\n>   (use \"git commit --amend\" to amend the current commit)\n>   (use \"git rebase --continue\" once you are satisfied with your changes)\n> \n> Changes not staged for commit:\n>   (use \"git add <file>...\" to update what will be committed)\n>   (use \"git checkout -- <file>...\" to discard changes in working directory)\n> \n> modified:   Mopy/Docs/Bash Readme Template.html\n> \n> Untracked files:\n>   (use \"git add <file>...\" to include in what will be committed)\n> \n> .DS_Store\n> .idea.7z\n> \n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> $\n> \n> I really hope someone here can debug this\n> Thanks!\n"},{"id":"365382","messageId":"CABRG_PHC+iufcv2j4CMLHioBZ7sea5qvYzsohzxDaiGwEW0R1g@mail.gmail.com","threadId":"50038","inReplyTo":"CAJdN7KitOpH=WFJW2SgU8mt75pFzF2mhD0TrCkyfnYugRdTkxw@mail.gmail.com","subject":"Re: Bug in lineendings handling that prevents resetting checking out, rebasing etc","fromName":"Mr&Mrs D","fromEmail":"the.ubik@gmail.com","sentAt":"2018-12-14T21:32:54Z","receivedAt":"2018-12-14T21:33:33Z","isPatch":false,"sender":{"key":"the.ubik@gmail.com","avatar":"https://gravatar.com/avatar/1d625f1bf89affc956dae8519e1b65ed5d970523db6170104cbee0c3162a17e4?d=mp&s=160"},"body":"$ git --version\ngit version 2.19.2\n\nMac os mojave\n\nHmm the latest version here: https://git-scm.com/download/mac seems to\nbe this one - where do I get 2.20?\n\nThanks!\nOn Fri, Dec 14, 2018 at 4:22 PM John Passaro <john.a.passaro@gmail.com> wrote:\n>\n> On Fri, Dec 14, 2018 at 4:08 PM Mr&Mrs D <the.ubik@gmail.com> wrote:\n> >\n> > Hi all,\n> >\n> > I maintain a python project you can clone from:\n> >\n> > git@github.com:wrye-bash/wrye-bash.git\n> >\n> > For reasons unknown git sees a particular file as changed\n> > (Mopy/Docs/Bash Readme Template.html, sometimes others too). This file\n> > was probably committed to the svn repository this git repo was created\n> > from with CRLF line endings. When we moved to git we added a\n> > gitattributes file (\n> > https://github.com/wrye-bash/wrye-bash/blob/dev/.gitattributes ) and\n> > this file was edited to explicitly state htms are text - all to no\n> > avail. From time to time - on windows - as in when checking out an old\n> > commit - git would see that file as changed. The only workaround that\n> > worked for me was\n> >\n> >     git rm -r . --cached -q && git reset --hard\n> >\n> > For more details and discussion see this SO question I posted almost\n> > five years ago:\n> >\n> > https://stackoverflow.com/questions/21122094/git-line-endings-cant-stash-reset-and-now-cant-rebase-over-spurious-line-en\n> >\n> > I used to work in windows and the bug was tolerable as there was that\n> > workaround. Now I moved to mac and no workaround works anymore - we\n> > have a special page on our wiki  with workarounds for this one btw:\n> >\n> > https://github.com/wrye-bash/wrye-bash/wiki/%5Bgit%5D-Issues-with-line-endings-preventing-checking,-merge,-etc\n> >\n> > Well after 5 years and countless hours trying to solve this I reach\n> > out to you guys and girls - _this is a full-time bug in git line\n> > endings handling_. When someone issues a git reset --hard this should\n> > work no matter what - well it does not. So this bug may be really a\n> > can of worms.\n> >\n> > Please someone clone this repo on linux or mac - probably just cloning\n> > will have the files appear as changed (by the way hitting refresh on\n> > git gui I have different sets of files appear as changed). If not then\n> >\n> > git checkout utumno-wip\n> > git rebase -i dev\n> >\n> > and then select a commit to edit should be enough to trigger this bug\n>\n> Does not reproduce on git 2.20.0 (mac high sierra fwiw). What version of git\n> are you using?\n> >\n> > Needless to say I am  well aware of things like `git add --renormalize\n> > .` - but renormalizing is not the issue. The issue is that _files show\n> > as changed and even a git reset --hard won't convince git that\n> > nothing's changed_.\n> >\n> > $ git reset --hard\n> > HEAD is now at e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n> > $ git status\n> > interactive rebase in progress; onto 02ae6f26\n> > Last commands done (4 commands done):\n> >    pick 3a39a0c0 Monkey patch for undecodable inis:\n> >    pick e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n> >   (see more in file .git/rebase-merge/done)\n> > Next commands to do (19 remaining commands):\n> >    edit a3a7b237 Amend last commit and linefixes:  ΕΕΕΕ\n> >    edit 432fd314 fFF handle empty or malformed inis\n> >   (use \"git rebase --edit-todo\" to view and edit)\n> > You are currently editing a commit while rebasing branch 'utumno-wip'\n> > on '02ae6f26'.\n> >   (use \"git commit --amend\" to amend the current commit)\n> >   (use \"git rebase --continue\" once you are satisfied with your changes)\n> >\n> > Changes not staged for commit:\n> >   (use \"git add <file>...\" to update what will be committed)\n> >   (use \"git checkout -- <file>...\" to discard changes in working directory)\n> >\n> > modified:   Mopy/Docs/Bash Readme Template.html\n> >\n> > Untracked files:\n> >   (use \"git add <file>...\" to include in what will be committed)\n> >\n> > .DS_Store\n> > .idea.7z\n> >\n> > no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> > $\n> >\n> > I really hope someone here can debug this\n> > Thanks!\n"},{"id":"365384","messageId":"CABRG_PG+D73XPDy3RV1-5yJvSuKDV9ymjT6pp5Jt5DoVsLZT8A@mail.gmail.com","threadId":"50038","inReplyTo":"20181214213246.GA2182@tor.lan","subject":"Re: Bug in lineendings handling that prevents resetting checking out, rebasing etc","fromName":"Mr&Mrs D","fromEmail":"the.ubik@gmail.com","sentAt":"2018-12-14T21:51:54Z","receivedAt":"2018-12-14T21:52:34Z","isPatch":false,"sender":{"key":"the.ubik@gmail.com","avatar":"https://gravatar.com/avatar/1d625f1bf89affc956dae8519e1b65ed5d970523db6170104cbee0c3162a17e4?d=mp&s=160"},"body":"Thanks for looking to it - git attributes was added in\n4b0863a8b834c5804fd3a568ed56ff85b27acdeb\n\nThe file in question was added in 17ca75f0a8c25f321f2b63bc3b9c065ff91adc23\n\nSo you mean to say that because a gitattributes was added after the\nfact this resulted in an illegal state?\n\nBut _shouldn't git reset --hard work anyway?_ That's the buggy part.\n\nAs for fixing it - not sure what is the best course of action here.\nprobably issuing `git add --renormalize .` and committing that to the\nstable (dev) branch will fix this for future checkouts/rebases but\nIIUC won't do nothing for older commits - so checking out a commit\nbefore the fix one, ghit will see this file as changed and then\ncompletely refuse to go back to another branch\n\nThis seems a bug - as illegal as the state of the file is, shouldn't\ngit reset always work?\n\nThanks! (will be out for a bit but really looking forward to your replies)\nOn Fri, Dec 14, 2018 at 4:32 PM Torsten Bögershausen <tboegi@web.de> wrote:\n>\n> On Fri, Dec 14, 2018 at 04:04:15PM -0500, Mr&Mrs D wrote:\n> > Hi all,\n> >\n> > I maintain a python project you can clone from:\n> >\n> > git@github.com:wrye-bash/wrye-bash.git\n> >\n> > For reasons unknown git sees a particular file as changed\n> > (Mopy/Docs/Bash Readme Template.html, sometimes others too). This file\n> > was probably committed to the svn repository this git repo was created\n> > from with CRLF line endings. When we moved to git we added a\n> > gitattributes file (\n> > https://github.com/wrye-bash/wrye-bash/blob/dev/.gitattributes ) and\n> > this file was edited to explicitly state htms are text - all to no\n> > avail. From time to time - on windows - as in when checking out an old\n> > commit - git would see that file as changed. The only workaround that\n> > worked for me was\n> >\n> >     git rm -r . --cached -q && git reset --hard\n> >\n> > For more details and discussion see this SO question I posted almost\n> > five years ago:\n> >\n> > https://stackoverflow.com/questions/21122094/git-line-endings-cant-stash-reset-and-now-cant-rebase-over-spurious-line-en\n> >\n> > I used to work in windows and the bug was tolerable as there was that\n> > workaround. Now I moved to mac and no workaround works anymore - we\n> > have a special page on our wiki  with workarounds for this one btw:\n> >\n> > https://github.com/wrye-bash/wrye-bash/wiki/%5Bgit%5D-Issues-with-line-endings-preventing-checking,-merge,-etc\n> >\n> > Well after 5 years and countless hours trying to solve this I reach\n> > out to you guys and girls - _this is a full-time bug in git line\n> > endings handling_. When someone issues a git reset --hard this should\n> > work no matter what - well it does not. So this bug may be really a\n> > can of worms.\n> >\n> > Please someone clone this repo on linux or mac - probably just cloning\n> > will have the files appear as changed (by the way hitting refresh on\n> > git gui I have different sets of files appear as changed). If not then\n> >\n> > git checkout utumno-wip\n> Thet commit is -excuse me if that sounds too harsh- is messed up.\n> git status says\n> modified:   Mopy/Docs/Bash Readme Template.html\n>\n> And if I dig into the EOL stuff, I run\n> git ls-files --eol | grep  Readme | less\n>\n> And find a contradiction here:\n> i/crlf  w/crlf  attr/text               Mopy/Docs/Bash Readme Template.html\n>\n> The attributes say \"text\" and the file has CRLF \"in the repo\",\n> (techically speaking in the index) and that is an \"illegal\" condition\n> in the repo, and not a bug in Git.\n> I didn't try the rebase as such, sice the first problem needs\n> to be fixed, before we try to move on.\n>\n> So, the old commits are problematic/illegal and they are as they are.\n> Such a commit can not be fixed, whenever somebody checks it out,\n> there will be a problem (or two, or none, depending on the timing,\n> the file system...)\n>\n> We can not fix commits like b1acc012878c9fdd8b4ad610ce7eae0dcbcbcab0.\n> We can make new commits, and fix them.\n>\n> We can fix one branch, and other branches, and merge them together.\n> But rebase seems to be problamatic, at least to me.\n> What exactly do you want to do?\n>\n> Can we agree to do a merge of 2 branches?\n> Then I can possibly help you out.\n>\n>\n>\n>\n>\n> > git rebase -i dev\n> >\n> > and then select a commit to edit should be enough to trigger this bug\n> >\n> > Needless to say I am  well aware of things like `git add --renormalize\n> > .` - but renormalizing is not the issue. The issue is that _files show\n> > as changed and even a git reset --hard won't convince git that\n> > nothing's changed_.\n> >\n> > $ git reset --hard\n> > HEAD is now at e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n> > $ git status\n> > interactive rebase in progress; onto 02ae6f26\n> > Last commands done (4 commands done):\n> >    pick 3a39a0c0 Monkey patch for undecodable inis:\n> >    pick e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n> >   (see more in file .git/rebase-merge/done)\n> > Next commands to do (19 remaining commands):\n> >    edit a3a7b237 Amend last commit and linefixes:  ΕΕΕΕ\n> >    edit 432fd314 fFF handle empty or malformed inis\n> >   (use \"git rebase --edit-todo\" to view and edit)\n> > You are currently editing a commit while rebasing branch 'utumno-wip'\n> > on '02ae6f26'.\n> >   (use \"git commit --amend\" to amend the current commit)\n> >   (use \"git rebase --continue\" once you are satisfied with your changes)\n> >\n> > Changes not staged for commit:\n> >   (use \"git add <file>...\" to update what will be committed)\n> >   (use \"git checkout -- <file>...\" to discard changes in working directory)\n> >\n> > modified:   Mopy/Docs/Bash Readme Template.html\n> >\n> > Untracked files:\n> >   (use \"git add <file>...\" to include in what will be committed)\n> >\n> > .DS_Store\n> > .idea.7z\n> >\n> > no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> > $\n> >\n> > I really hope someone here can debug this\n> > Thanks!\n"},{"id":"365424","messageId":"20181215044345.GA19192@tor.lan","threadId":"50038","inReplyTo":"CABRG_PG+D73XPDy3RV1-5yJvSuKDV9ymjT6pp5Jt5DoVsLZT8A@mail.gmail.com","subject":"Re: Bug in lineendings handling that prevents resetting checking out, rebasing etc","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2018-12-15T04:43:45Z","receivedAt":"2018-12-15T04:43:53Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On Fri, Dec 14, 2018 at 04:51:54PM -0500, Mr&Mrs D wrote:\n> Thanks for looking to it - git attributes was added in\n> 4b0863a8b834c5804fd3a568ed56ff85b27acdeb\n> \n> The file in question was added in 17ca75f0a8c25f321f2b63bc3b9c065ff91adc23\n> \n> So you mean to say that because a gitattributes was added after the\n> fact this resulted in an illegal state?\n> \n> But _shouldn't git reset --hard work anyway?_ That's the buggy part.\n\nYes and no.\nIf I look at the dev branch:\ncommit 02ae6f264f340137b8b41ba6953e2a4f962c222e (HEAD, origin/dev, origin/HEAD, dev)\n\nNow we can ask Git, why a file is modified:\n\ngit ls-files --eol | grep \"Mopy/Docs/Bash eadme Template.html\"\ni/crlf  w/crlf  attr/text               Mopy/Docs/Bash Readme Template.html\n\nNow we have 2 conflicting \"messages\" to Git:\na) \"Mopy/Docs/Bash Readme Template.html\" has the attribute \"text\"\nb) \"Mopy/Docs/Bash Readme Template.html\" has been commited with CRLF.\n\nGit itself can not resolve this conflict.\nEither you normalize the repo (in this case only 1 file), other commits have 4 files\nthat needs to be normalized.\nOr you change the attribute into \"text=auto\".\n\nThat decision is up to the user.\n\n> \n> As for fixing it - not sure what is the best course of action here.\n> probably issuing `git add --renormalize .` and committing that to the\n> stable (dev) branch will fix this for future checkouts/rebases but\n> IIUC won't do nothing for older commits - so checking out a commit\n> before the fix one, ghit will see this file as changed and then\n> completely refuse to go back to another branch\n> \n> This seems a bug - as illegal as the state of the file is, shouldn't\n> git reset always work?\n> \n> Thanks! (will be out for a bit but really looking forward to your replies)\n> On Fri, Dec 14, 2018 at 4:32 PM Torsten Bögershausen <tboegi@web.de> wrote:\n> >\n> > On Fri, Dec 14, 2018 at 04:04:15PM -0500, Mr&Mrs D wrote:\n> > > Hi all,\n> > >\n> > > I maintain a python project you can clone from:\n> > >\n> > > git@github.com:wrye-bash/wrye-bash.git\n> > >\n> > > For reasons unknown git sees a particular file as changed\n> > > (Mopy/Docs/Bash Readme Template.html, sometimes others too). This file\n> > > was probably committed to the svn repository this git repo was created\n> > > from with CRLF line endings. When we moved to git we added a\n> > > gitattributes file (\n> > > https://github.com/wrye-bash/wrye-bash/blob/dev/.gitattributes ) and\n> > > this file was edited to explicitly state htms are text - all to no\n> > > avail. From time to time - on windows - as in when checking out an old\n> > > commit - git would see that file as changed. The only workaround that\n> > > worked for me was\n> > >\n> > >     git rm -r . --cached -q && git reset --hard\n> > >\n> > > For more details and discussion see this SO question I posted almost\n> > > five years ago:\n> > >\n> > > https://stackoverflow.com/questions/21122094/git-line-endings-cant-stash-reset-and-now-cant-rebase-over-spurious-line-en\n> > >\n> > > I used to work in windows and the bug was tolerable as there was that\n> > > workaround. Now I moved to mac and no workaround works anymore - we\n> > > have a special page on our wiki  with workarounds for this one btw:\n> > >\n> > > https://github.com/wrye-bash/wrye-bash/wiki/%5Bgit%5D-Issues-with-line-endings-preventing-checking,-merge,-etc\n> > >\n> > > Well after 5 years and countless hours trying to solve this I reach\n> > > out to you guys and girls - _this is a full-time bug in git line\n> > > endings handling_. When someone issues a git reset --hard this should\n> > > work no matter what - well it does not. So this bug may be really a\n> > > can of worms.\n> > >\n> > > Please someone clone this repo on linux or mac - probably just cloning\n> > > will have the files appear as changed (by the way hitting refresh on\n> > > git gui I have different sets of files appear as changed). If not then\n> > >\n> > > git checkout utumno-wip\n> > Thet commit is -excuse me if that sounds too harsh- is messed up.\n> > git status says\n> > modified:   Mopy/Docs/Bash Readme Template.html\n> >\n> > And if I dig into the EOL stuff, I run\n> > git ls-files --eol | grep  Readme | less\n> >\n> > And find a contradiction here:\n> > i/crlf  w/crlf  attr/text               Mopy/Docs/Bash Readme Template.html\n> >\n> > The attributes say \"text\" and the file has CRLF \"in the repo\",\n> > (techically speaking in the index) and that is an \"illegal\" condition\n> > in the repo, and not a bug in Git.\n> > I didn't try the rebase as such, sice the first problem needs\n> > to be fixed, before we try to move on.\n> >\n> > So, the old commits are problematic/illegal and they are as they are.\n> > Such a commit can not be fixed, whenever somebody checks it out,\n> > there will be a problem (or two, or none, depending on the timing,\n> > the file system...)\n> >\n> > We can not fix commits like b1acc012878c9fdd8b4ad610ce7eae0dcbcbcab0.\n> > We can make new commits, and fix them.\n> >\n> > We can fix one branch, and other branches, and merge them together.\n> > But rebase seems to be problamatic, at least to me.\n> > What exactly do you want to do?\n> >\n> > Can we agree to do a merge of 2 branches?\n> > Then I can possibly help you out.\n> >\n> >\n> >\n> >\n> >\n> > > git rebase -i dev\n> > >\n> > > and then select a commit to edit should be enough to trigger this bug\n> > >\n> > > Needless to say I am  well aware of things like `git add --renormalize\n> > > .` - but renormalizing is not the issue. The issue is that _files show\n> > > as changed and even a git reset --hard won't convince git that\n> > > nothing's changed_.\n> > >\n> > > $ git reset --hard\n> > > HEAD is now at e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n> > > $ git status\n> > > interactive rebase in progress; onto 02ae6f26\n> > > Last commands done (4 commands done):\n> > >    pick 3a39a0c0 Monkey patch for undecodable inis:\n> > >    pick e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n> > >   (see more in file .git/rebase-merge/done)\n> > > Next commands to do (19 remaining commands):\n> > >    edit a3a7b237 Amend last commit and linefixes:  ΕΕΕΕ\n> > >    edit 432fd314 fFF handle empty or malformed inis\n> > >   (use \"git rebase --edit-todo\" to view and edit)\n> > > You are currently editing a commit while rebasing branch 'utumno-wip'\n> > > on '02ae6f26'.\n> > >   (use \"git commit --amend\" to amend the current commit)\n> > >   (use \"git rebase --continue\" once you are satisfied with your changes)\n> > >\n> > > Changes not staged for commit:\n> > >   (use \"git add <file>...\" to update what will be committed)\n> > >   (use \"git checkout -- <file>...\" to discard changes in working directory)\n> > >\n> > > modified:   Mopy/Docs/Bash Readme Template.html\n> > >\n> > > Untracked files:\n> > >   (use \"git add <file>...\" to include in what will be committed)\n> > >\n> > > .DS_Store\n> > > .idea.7z\n> > >\n> > > no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> > > $\n> > >\n> > > I really hope someone here can debug this\n> > > Thanks!\n"},{"id":"365436","messageId":"CABRG_PHuRc59mp6PLO49vEn50OkPv5uwv3RyTdVZ=25MWU7dTQ@mail.gmail.com","threadId":"50038","inReplyTo":"20181215044345.GA19192@tor.lan","subject":"Re: Bug in lineendings handling that prevents resetting checking out, rebasing etc","fromName":"Mr&Mrs D","fromEmail":"the.ubik@gmail.com","sentAt":"2018-12-15T20:58:49Z","receivedAt":"2018-12-15T20:59:28Z","isPatch":false,"sender":{"key":"the.ubik@gmail.com","avatar":"https://gravatar.com/avatar/1d625f1bf89affc956dae8519e1b65ed5d970523db6170104cbee0c3162a17e4?d=mp&s=160"},"body":"Thanks again!\n\nWhichever path I take all the intermediate commits between the fix\ncommit and the one that added the gitattributes file (so marked that\nfile as text) will be plagued by this - checking them out on linux or\nmacos will show that particular file as modified. Is my understanding\ncorrect?\nIt still seems to me that at least the operating system should not\nmatter here - I did not encounter this on windows and when I did (as\ndescribed in the SO post) `git rm -r . --cached -q && git reset\n--hard` would reset the branch.\n\nIs there a way I can add this file to local .git/info/attributes so\nthat I overwrite the .gitattributes (see\nhttps://stackoverflow.com/a/33715791/281545 ) ?\n\nI tried adding the line:\n\n$ cat .git/info/attributes\nMopy/Docs/Bash Readme Template.html -text\n\nbut does nothing. The idea would be to add the commit fixing the line\nendings on the stable branch and also instruct collaborators to edit\ntheir .git/info/attributes files so when checking out older commits\nthe file does not show as changed.\n\nSpeaking of line endings fix issuing:\n\n(dev) $ git add --renormalize .\n(dev) $ git status\nOn branch dev\nYour branch is up to date with 'origin/dev'.\n\nChanges to be committed:\n  (use \"git reset HEAD <file>...\" to unstage)\n\nmodified:   Mopy/Docs/Bash Readme Template.html\nmodified:   Mopy/Docs/Bash Readme Template.txt\nmodified:   Mopy/bash/db/Oblivion_ids.pkl\nmodified:   Mopy/bash/db/Skyrim_ids.pkl\n\nUntracked files:\n...\n\nadds 4 files as seen (?)\n\nThanks again and sorry for the late reply\nOn Fri, Dec 14, 2018 at 11:43 PM Torsten Bögershausen <tboegi@web.de> wrote:\n>\n> On Fri, Dec 14, 2018 at 04:51:54PM -0500, Mr&Mrs D wrote:\n> > Thanks for looking to it - git attributes was added in\n> > 4b0863a8b834c5804fd3a568ed56ff85b27acdeb\n> >\n> > The file in question was added in 17ca75f0a8c25f321f2b63bc3b9c065ff91adc23\n> >\n> > So you mean to say that because a gitattributes was added after the\n> > fact this resulted in an illegal state?\n> >\n> > But _shouldn't git reset --hard work anyway?_ That's the buggy part.\n>\n> Yes and no.\n> If I look at the dev branch:\n> commit 02ae6f264f340137b8b41ba6953e2a4f962c222e (HEAD, origin/dev, origin/HEAD, dev)\n>\n> Now we can ask Git, why a file is modified:\n>\n> git ls-files --eol | grep \"Mopy/Docs/Bash eadme Template.html\"\n> i/crlf  w/crlf  attr/text               Mopy/Docs/Bash Readme Template.html\n>\n> Now we have 2 conflicting \"messages\" to Git:\n> a) \"Mopy/Docs/Bash Readme Template.html\" has the attribute \"text\"\n> b) \"Mopy/Docs/Bash Readme Template.html\" has been commited with CRLF.\n>\n> Git itself can not resolve this conflict.\n> Either you normalize the repo (in this case only 1 file), other commits have 4 files\n> that needs to be normalized.\n> Or you change the attribute into \"text=auto\".\n>\n> That decision is up to the user.\n>\n> >\n> > As for fixing it - not sure what is the best course of action here.\n> > probably issuing `git add --renormalize .` and committing that to the\n> > stable (dev) branch will fix this for future checkouts/rebases but\n> > IIUC won't do nothing for older commits - so checking out a commit\n> > before the fix one, ghit will see this file as changed and then\n> > completely refuse to go back to another branch\n> >\n> > This seems a bug - as illegal as the state of the file is, shouldn't\n> > git reset always work?\n> >\n> > Thanks! (will be out for a bit but really looking forward to your replies)\n> > On Fri, Dec 14, 2018 at 4:32 PM Torsten Bögershausen <tboegi@web.de> wrote:\n> > >\n> > > On Fri, Dec 14, 2018 at 04:04:15PM -0500, Mr&Mrs D wrote:\n> > > > Hi all,\n> > > >\n> > > > I maintain a python project you can clone from:\n> > > >\n> > > > git@github.com:wrye-bash/wrye-bash.git\n> > > >\n> > > > For reasons unknown git sees a particular file as changed\n> > > > (Mopy/Docs/Bash Readme Template.html, sometimes others too). This file\n> > > > was probably committed to the svn repository this git repo was created\n> > > > from with CRLF line endings. When we moved to git we added a\n> > > > gitattributes file (\n> > > > https://github.com/wrye-bash/wrye-bash/blob/dev/.gitattributes ) and\n> > > > this file was edited to explicitly state htms are text - all to no\n> > > > avail. From time to time - on windows - as in when checking out an old\n> > > > commit - git would see that file as changed. The only workaround that\n> > > > worked for me was\n> > > >\n> > > >     git rm -r . --cached -q && git reset --hard\n> > > >\n> > > > For more details and discussion see this SO question I posted almost\n> > > > five years ago:\n> > > >\n> > > > https://stackoverflow.com/questions/21122094/git-line-endings-cant-stash-reset-and-now-cant-rebase-over-spurious-line-en\n> > > >\n> > > > I used to work in windows and the bug was tolerable as there was that\n> > > > workaround. Now I moved to mac and no workaround works anymore - we\n> > > > have a special page on our wiki  with workarounds for this one btw:\n> > > >\n> > > > https://github.com/wrye-bash/wrye-bash/wiki/%5Bgit%5D-Issues-with-line-endings-preventing-checking,-merge,-etc\n> > > >\n> > > > Well after 5 years and countless hours trying to solve this I reach\n> > > > out to you guys and girls - _this is a full-time bug in git line\n> > > > endings handling_. When someone issues a git reset --hard this should\n> > > > work no matter what - well it does not. So this bug may be really a\n> > > > can of worms.\n> > > >\n> > > > Please someone clone this repo on linux or mac - probably just cloning\n> > > > will have the files appear as changed (by the way hitting refresh on\n> > > > git gui I have different sets of files appear as changed). If not then\n> > > >\n> > > > git checkout utumno-wip\n> > > Thet commit is -excuse me if that sounds too harsh- is messed up.\n> > > git status says\n> > > modified:   Mopy/Docs/Bash Readme Template.html\n> > >\n> > > And if I dig into the EOL stuff, I run\n> > > git ls-files --eol | grep  Readme | less\n> > >\n> > > And find a contradiction here:\n> > > i/crlf  w/crlf  attr/text               Mopy/Docs/Bash Readme Template.html\n> > >\n> > > The attributes say \"text\" and the file has CRLF \"in the repo\",\n> > > (techically speaking in the index) and that is an \"illegal\" condition\n> > > in the repo, and not a bug in Git.\n> > > I didn't try the rebase as such, sice the first problem needs\n> > > to be fixed, before we try to move on.\n> > >\n> > > So, the old commits are problematic/illegal and they are as they are.\n> > > Such a commit can not be fixed, whenever somebody checks it out,\n> > > there will be a problem (or two, or none, depending on the timing,\n> > > the file system...)\n> > >\n> > > We can not fix commits like b1acc012878c9fdd8b4ad610ce7eae0dcbcbcab0.\n> > > We can make new commits, and fix them.\n> > >\n> > > We can fix one branch, and other branches, and merge them together.\n> > > But rebase seems to be problamatic, at least to me.\n> > > What exactly do you want to do?\n> > >\n> > > Can we agree to do a merge of 2 branches?\n> > > Then I can possibly help you out.\n> > >\n> > >\n> > >\n> > >\n> > >\n> > > > git rebase -i dev\n> > > >\n> > > > and then select a commit to edit should be enough to trigger this bug\n> > > >\n> > > > Needless to say I am  well aware of things like `git add --renormalize\n> > > > .` - but renormalizing is not the issue. The issue is that _files show\n> > > > as changed and even a git reset --hard won't convince git that\n> > > > nothing's changed_.\n> > > >\n> > > > $ git reset --hard\n> > > > HEAD is now at e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n> > > > $ git status\n> > > > interactive rebase in progress; onto 02ae6f26\n> > > > Last commands done (4 commands done):\n> > > >    pick 3a39a0c0 Monkey patch for undecodable inis:\n> > > >    pick e5c16790 Wip proper handling of ini tweaks encoding - TODOs:\n> > > >   (see more in file .git/rebase-merge/done)\n> > > > Next commands to do (19 remaining commands):\n> > > >    edit a3a7b237 Amend last commit and linefixes:  ΕΕΕΕ\n> > > >    edit 432fd314 fFF handle empty or malformed inis\n> > > >   (use \"git rebase --edit-todo\" to view and edit)\n> > > > You are currently editing a commit while rebasing branch 'utumno-wip'\n> > > > on '02ae6f26'.\n> > > >   (use \"git commit --amend\" to amend the current commit)\n> > > >   (use \"git rebase --continue\" once you are satisfied with your changes)\n> > > >\n> > > > Changes not staged for commit:\n> > > >   (use \"git add <file>...\" to update what will be committed)\n> > > >   (use \"git checkout -- <file>...\" to discard changes in working directory)\n> > > >\n> > > > modified:   Mopy/Docs/Bash Readme Template.html\n> > > >\n> > > > Untracked files:\n> > > >   (use \"git add <file>...\" to include in what will be committed)\n> > > >\n> > > > .DS_Store\n> > > > .idea.7z\n> > > >\n> > > > no changes added to commit (use \"git add\" and/or \"git commit -a\")\n> > > > $\n> > > >\n> > > > I really hope someone here can debug this\n> > > > Thanks!\n"}]}