Re: Cannot checkout after setting the eol attribute
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
Re: Cannot checkout after setting the eol attribute
On Tue, Aug 22, 2017 at 03:44:41PM -0400, Ben Boeckel wrote: > 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 :) . 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. > > > 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? 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 > 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...
Re: Cannot checkout after setting the eol attribute
Torsten Bögershausenwrites: > 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 >git add dos This is not advisable as a general suggestion, as in a real life (as opposed to a toy example) there will be paths other than this 'dos' thing in the working tree. Perhaps replace "git read-tree --empty" with "git rm -f --cached dos" or something like that that limits its damage would prevent mistakes better. >git add .gitattributes >git commit -m "set eol attribute instead" >git ls-files --eol
Re: Cannot checkout after setting the eol attribute
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
Re: Cannot checkout after setting the eol attribute
On Tue, Aug 22, 2017 at 01:49:18PM -0400, Ben Boeckel wrote: > Hi, > > I specified the `eol` attribute on some files recently and the behavior > of Git is very strange. > > Here is the set of commands to set up the repository used for the > discussion: > > 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 add .gitattributes > git commit -m "set eol attribute instead" > > The following behaviors are observed: > > - `git reset --hard` does not make the working directory clean; and > - `git rebase` gets *very* confused about the diffs in the working > tree because `git stash` can't reset the working tree; > > There are probably other oddities lingering about as well. If I commit > what Git thinks is the difference, the diff (with invisibles made > visible) is: > > % git diff | cat -A > diff --git a/dos b/dos$ > index fde2310..4723a1b 100644$ > --- a/dos$ > +++ b/dos$ > @@ -1 +1 @@$ > -dos^M$ > +dos$ Thanks for the goos example! This is by design. 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 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. 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 git add dos git add .gitattributes git commit -m "set eol attribute instead" git ls-files --eol > > Seen in 2.9.5 and 2.14.0.rc1. > > --Ben
Cannot checkout after setting the eol attribute
Hi, I specified the `eol` attribute on some files recently and the behavior of Git is very strange. Here is the set of commands to set up the repository used for the discussion: 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 add .gitattributes git commit -m "set eol attribute instead" The following behaviors are observed: - `git reset --hard` does not make the working directory clean; and - `git rebase` gets *very* confused about the diffs in the working tree because `git stash` can't reset the working tree; There are probably other oddities lingering about as well. If I commit what Git thinks is the difference, the diff (with invisibles made visible) is: % git diff | cat -A diff --git a/dos b/dos$ index fde2310..4723a1b 100644$ --- a/dos$ +++ b/dos$ @@ -1 +1 @@$ -dos^M$ +dos$ Seen in 2.9.5 and 2.14.0.rc1. --Ben