On Tue, Aug 22, 2017 at 21:13:18 +0200, Torsten Bögershausen wrote: > When you set the text attribute (in your case "eol=crlf" implies text) > then the file(s) -must- be nomalized and commited so that they have LF > in the repo (technically speaking the index) This seems like a special case that Git could detect and message about somehow. > This is what is written about the "eol=crlf" attribute: > This setting forces Git to normalize line endings for this > file on checkin and convert them to CRLF when the file is > checked out. > And this is what is implemented in Git. Yeah, I read the docs, but the oddities of reset not doing its job wasn't clear from this sentence :) . > Long story short: > > The following would solve your problem: > git init > echo $'dos\r' > dos > git add dos > git commit -m "dos newlines" > echo "dos -crlf" > .gitattributes > git add .gitattributes > git commit -m "add attributes" > echo "dos eol=crlf" > .gitattributes > git read-tree --empty # Clean index, force re-scan of working directory The fact that plumbing is necessary to dig yourself out of a hole of the `eol` attribute changes points to something needing to be changed, even if it's only documentation. Could Git detect this and message about it somehow when `git reset` cannot fix the working tree? Or maybe it could at least exit with failure instead of success? --Ben
