Re: What's cooking extra
- From
Erik Faye-Lund <kusmabite@googlemail.com>
- Date
- May 24, 2010, 12:22 UTC
- Message-ID
- <AANLkTil83LQrMiAtAQwgfCtI6jeBHHq-P3DyjrIjcNtz@mail.gmail.com>
- In-Reply-To
- <20100524121224.GB3005@dpotapov.dyndns.org>
On Mon, May 24, 2010 at 2:12 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
Show 23 quoted lines
> On Sun, May 23, 2010 at 01:51:27PM +0200, Clemens Buchacher wrote: >> On Sun, May 23, 2010 at 12:36:51PM +0200, Eyvind Bernhardsen wrote: >> > >> > Actually, since git normalizes to LF, "eol=lf" simply means >> > "convert on input but not on output", which is what >> > "core.autocrlf=input" currently does. The fact that you didn't >> > know this reflects the poor usability of core.autocrlf, which is >> > one of the things this series is trying to rectify :) >> >> No, I am aware of autocrlf=input, but apparently I did not >> understand the meaning of eol=lf correctly. So if a file has CRLF >> endings in the repository, and eol=lf, it will _not_ be converted >> to LF in the work tree? Conversely, if it has LF endings in the >> repository, and eol=crlf, it _will_ be converted to CRLF in the >> work tree? > > All text files should LF in the repository, if some file does not, it > means the repository is corrupted in respect of handling text files. > So, the situation is not symmetric at all! I don't know how better to > handle this "corruption". I guess, it should be a warning about some > files having different ending that it should have had based on their > attributes. >
I thought the original motivation behind this change was to make repos with CRLF-textfiles work without reporting diffs on all lines when autocrlf was enabled. Because checking in CRLF-files DOES happen, and for some of us the reality is that we have to deal with such repos.
Perhaps I'm confusing this discussion with some other, though.
-- Erik "kusma" Faye-Lund