On Mon, Jan 08, 2018 at 03:38:48PM +0100, Lars Schneider wrote: [] > > Some comments: > > > > I would like to have the CRLF conversion a little bit more strict - > > many users tend to set core.autocrlf=true or write "* text=auto" > > in the .gitattributes. > > Reading all the effort about BOM markers and UTF-16LE, I think there > > should ne some effort to make the line endings round trip. > > Therefore I changed convert.c to demand that the "text" attribute > > is set to enable CRLF conversions. > > (If I had submitted the patch, I would have demanded > > "text eol=lf" or "text eol=crlf", but the test case t0028 indicates > > that there is a demand to produce line endings as configured in core.eol) > > But wouldn't that be inconvenient for the users? E.g. if I add a UTF-16 > file on Windows with CRLF then it would be nice if Git would automatically > convert the line endings to LF on Linux, no? > > IOW: Why should we handle text files that have a defined checkout-encoding > differently compared to UTF-8 encoded text files? Wouldn't that be unexpected > to the user? > > Thanks, > Lars
The problem is, if user A has core.autocrlf=true and user B core.autocrlf=false. (The line endings don't show up as expected at user B) Having said that in all shortness, you convinced me: If text=auto, we care about line endings. If text, we care about line endings. If the .gitattributes don't say anything about text, we don't convert eol. (In other words: we don't look at core.autocrlf, when checkout-encoding is defined) A new branch is push to github/tboegi
