From: Ralf Thielow Date: Fri, 16 Dec 2011 22:36:07 GMT Subject: Re: [BUG] attribute "eol" with "crlf" Message-ID: In-Reply-To: <7vehw4go0v.fsf@alter.siamese.dyndns.org> Basicly I want to force the line endings of the files on my project. :/ 2011/12/16 Junio C Hamano : > Ralf Thielow writes: > >> So i have to commit ".gitattributes" and everything is fine for me after!? > > No.  Sorry if I was unclear, but I do not see which part was unclear in > what I wrote, so... > >>> The sequence adds "test\r\n" file without .gitattributes to have the >>> repository record that exact byte sequence for the file. But then later >>> goes around and says "This file wants to express the end of line with CRLF >>> on the filesystem, so please replace LF in the repository representation >>> to CRLF when checking out, and replace CRLF in the working tree to LF when >>> checking in". >>> >>> So it is not surprising that "\r\n" coming from the repository is replaced >>> to "\r\r\n" when checked out. As far as the repository data is concerned, >>> that line has a funny byte with value "\r" at the end, immediately before >>> the line terminator "\n". >>> >>> What you said is _technically_ correct in that sense. >>> >>> However, I think the CRLF filter used to have a hack to strip "\r" if the >>> repository data records "\r" at the end of line. This was intended to help >>> people who checked in such a broken text file (if it is a text file, then >>> raw ascii CR does not have a place in it in the repository representation) >>> and it was a useful hack to help people recover from such mistakes to >>> start the project from DOS-only world (with CRLF in the repository data) >>> and migrate to cross platform world (with LF in the repository data, CRLF >>> in the DOS working tree).  I suspect that the streaming filter conversion >>> may not have the same hack in it.