Re: [PATCH] Add "core.eol" variable to control end-of-line conversion
- From
Robert Buck <buck.robert.j@gmail.com>
- Date
- May 16, 2010, 10:39 UTC
- Message-ID
- <AANLkTin-KO8n591Hz7BuJCaHCe4osfCvUhH4ua0beyXt@mail.gmail.com>
- In-Reply-To
- <1273956445-67531-1-git-send-email-eyvind.bernhardsen@gmail.com>
On Sat, May 15, 2010 at 4:47 PM, Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> wrote:
Show 41 quoted lines
> Introduce a new configuration variable, "core.eol", that allows the user > to set which line endings to use for end-of-line-normalized files in the > working directory. It defaults to "native", which means CRLF on Windows > and LF everywhere else. > > For backwards compatibility, "core.autocrlf" will override core.eol if > core.eol is left unset. This means that > > [core] > autocrlf = true > > will give CRLFs in the working directory even on platforms with LF as > their native line ending. > > If core.eol is set explicitly (including setting it to "native"), it > will override core.autocrlf so that > > [core] > autocrlf = true > eol = lf > > normalizes all files that look like text, but does not put CRLFs in the > working directory. > > Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> > --- > > It turns out that my resistance to "core.eol" was mostly laziness, so I > just implemented it. > > I decided that "core.autocrlf" has to override the native line ending if > "core.eol" isn't set explicitly, which gives some extra complexity in > convert.c. > > For 1.8 I would consider making core.autocrlf just turn on normalization > and leave the working directory line ending decision to core.eol, but > that _will_ break people's setups. > > Patch is on top of my latest series. > -- > Eyvind
Looking forward to this change. In terms of usability it is really nice. Eager to see it in a release.