Subject: Re: CRLF problems with Git on Win32

From: Gregory Jefferis <[email-masked]>
Date: Thu, 10 Jan 2008 19:58:41 +0000

On 8/1/08 18:07, "Junio C Hamano" <[email-masked]> wrote:

> Steffen Prohaska <[email-masked]> writes:
> 
>> msysgit installs plain git.  core.autocrlf is unset.  Whatever plain
>> git's default is, this is msysgit's default, too.
> 
> That sounds like a mistake if you are installing a port to a
> platform whose native line ending convention is different from
> where plain git natively runs on (i.e. UNIX).

I'm not sure that I understand the whole deal about platform default line
endings.  Isn't plain git functionally agnostic about line endings?  You can
check in CRLF text files to git and it doesn't care.  You can diff, show etc
just fine.  I haven't yet found anything that breaks with CRLF files.  In
this sense plain git is already Windows ready.  Maybe I'm missing something?

Doesn't the problem only come if you try to diff a CRLF file with a new
version that has LF only line endings?  Then right now you have to use
something like:

    git diff --ignore-space-at-eol

Or if a Windows user clones a repository created on another system.  For
these cross-platform circumstances, it seems to me sensible to have an
option (probably enabled by default on all platforms) that allows files to
be munged on check in to whatever EOL style the repository creator preferred
(probably stored in .gitattributes and could be different for different
files in the repo - e.g. a windows vendor src dir on a cross-platform
project).  Note that this means that munging would only happen if someone
actually asked for it - which would be a sensible thing to do as the
administrator of a cross-platform project.

Then there would be a separate option (probably not enabled by default) to
check out with the platform's native line ending instead of whatever is in
the repo. This would allow people to work with inflexible toolsets.

Finally for people who want to work with native line endings that are
different from repository line endings, then it might be necessary to
improve the handling of diffs by providing a config var to make
--ignore-space-at-eol the default (or perhaps more correctly
--ignore-line-endings) for text files.  From my preliminary reading of list
history improving the inspection of content rather than trying to change
content might be the more gitish thing to do.

In conclusion all of these CRLF options are designed to help Windows users
play nicely with others.  But it seems to me naïve Windows users can be
perfectly happy with plain git so long as they stay in their own Windows
world.

jm2c, corrections welcome and apologies to those suffering from eol
exhaustion,

Greg.