git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: possible gitattributes eol bug with new eol=crlf | lf support?

From
Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Date
Sep 10, 2010, 18:25 UTC
Message-ID
<1F2D74A7-1C9C-47D9-9C3D-E430E446CB94@gmail.com>
In-Reply-To
<AANLkTinC8g9m=2ka=7LiHH4MtfxC-NbxbsYQEbmMyXmN@mail.gmail.com>
On 10. sep. 2010, at 00.31, Robert Buck wrote:
[...]
Show 6 quoted lines
> Conversion of LF-EOL files to CRLF works fine, but conversion of CRLF
> to LF fails to occur.
> 
> The doc is a little unclear if this is expected behavior, which if I
> recall correctly from the email threads related to the new eol
> support, this should not have occurred.
Unfortunately, this is expected behaviour: you need to "manually" remove CRLFs when you turn on eol conversion.  The simplest way to do this is "rm .git/index && git reset", then commit the modified files (ideally in the same commit that modifies .gitattributes--this is mentioned in gitattributes(5)).
To make this work as it should, git would have to notice changes to .gitattributes and check files which have had their attributes changed.  It's on my "I wish I had time to do this" list.
- Eyvind
Previous: Robert BuckNext: Robert Buck
Message 2 of 6 in “possible gitattributes eol bug with new eol=crlf | lf support?”
  1. Robert BuckSep 9, 2010
  2. Eyvind BernhardsenSep 10, 2010
  3. Robert BuckSep 10, 2010
  4. Eyvind BernhardsenSep 12, 2010
  5. Robert BuckSep 12, 2010
  6. Eyvind BernhardsenSep 13, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.