On Thu, Oct 4, 2012 at 12:35 AM, John Whitney <j...@emsoftware.com> wrote: > I just ran into a problem that I'm pretty sure is a bug in git. Just read > and run this (fairly trivial) shell script to replicate.
When you added "* text=auto" in the .gitattributes file, you changed what git considers to be the checked-in file content state for test.txt. The file contents in your working directory do not match what git expects to check in. Therefore, the file appears to be different. If you commit the file "changes" the problem goes away. This is more of a workaround than an a satisfying explanation. If you then checkout the original HEAD commit (but with .gitattributes present) you will see the problem appear again. But in a sense, adding .gitattributes this way is an act of foot-shooting. The best way forward may be to normalize your repository by removing all CR's from files in history. If you do not have this freedom, your best bet may be to normalize the repo in the current commit and move on. Others with more intimate insight into the CRLF journey in git's past may have better advice. Phil -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
