On Wed, Aug 23, 2017 at 21:43:15 +0200, Torsten Bögershausen wrote: > git reset does it's job - please see below. > > The problem is that we need a "git commit" here. > After applying .gitattributes, it may be neccessary to "normalize" the > files. If there is something in the documentation, that can be > improved, please let us know. I'll have a patch up shortly. > On Tue, Aug 22, 2017 at 03:44:41PM -0400, Ben Boeckel wrote: > > 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? > > The thing is, that the working tree is "in a good state": > We want "dos" with CRLF, and that is what we have. > There is nothing that can be improved in the working tree. > What needs to be fixed, is the index. And that needs to be done with > "git add" "git commit." > As Junio pointed out, the read-tree is not ideal > (to fix a single file in a possible dirty working tree) > > In your case it looks like this: > > echo "dos eol=crlf" > .gitattributes > git add .gitattributes && > git rm --cached dos && git add dos && > git commit In this case, just adding the file should work: the file is on-disk as intended and adding the file should normalize the line endings when adding it into the index (basically, just `git add dos` should be required to make the index look like it should). > > Or maybe it could at least exit with failure instead of success? > > I don't know. > It -may- be possible to add a warning in "git reset". > I can have a look at that... Thanks. --Ben
