Subject: Re: EOL handling (EGit/svn/Windows)

From: Torsten Bögershausen <[email-masked]>
Date: Tue, 10 Feb 2015 16:32:30 +0100

On 2015-02-10 11.52, Piotr Krukowiecki wrote:
> On Tue, Feb 10, 2015 at 6:49 AM, Torsten Bögershausen <[email-masked]> wrote:
>> Which Git versions are you using ?
> 
> The one I'm testing currently:
> 
> git version 1.7.9 (cygwin)
> git version 1.9.0.msysgit.0 (msys)
> EGit from Eclipse Luna
> 
> Cygwin git is a bit old, as I see now. Will try to update later.
> 
> 
>> How many people are there involved, how many on Windows, how many on Linux ?
> 
> Less than 10 actively, most on Windows.
> 
> 
>> Do you want to commit to svn, or is this a one-time conversion ?
> 
> One-time.
> 
> 
>> If it is a one-time conversion, and you continue to work in Git only,
>> then the cleanest, most portable and future proof way is to use the
>> .gitattributes file,
> 
> I'm not sure if EGit supports .gitattributes:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372
> 
> 
>> add that to the repo, do the normalization  and push.
>> A line like this:
>> * text=auto
>> is the easiest way.
> 
> I'm trying it.
> 
> 
>> Have a look at
>> https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
>> take a tee or coffee, do some experiments first with a dummy repo,
>> but all the client OS/Gits involved.
> 
> That's one step we did not do carefully enough :(
> 
> 
>> Please let us know the result (or feel free to ask more questions)
> 
> For testing, I've converted all files to LF and commited it, also
> added the .gitattribute file.
> 
> So far:
> 1. msysgit can't checkout a one file (saying filename too long, the
> relative path has 215 bytes) - probably not related to EOL issue.
Please have a look here:
https://github.com/msysgit/msysgit/releases/Git-1.9.5-preview20141217
I think we have support for long path names (Haven't tested it myself)
> Cygwin git works ok. So I did not check how msysgit works yet.
> 2. maybe due to old cygwin git, I have a problem of not displaying
> changes, if the changed line has LF eol (and the file was checked out
> on Windows with CRLF eols). Will try later with newer git.
Normally you will not see any changes, and "git diff" will not show
anything either.
> 2a. EGit handles such files gracefuly, but OTOH if the file is simple
> dos2unix'ed, it shows diffs showing all lines changed, and when you
> commit the files, it will create empty commit.
Why this dos2unix ?
Is there a special reason ?
By the way, when people only use Egit, I assume they use Eclipse,
and you don't use Notepad.exe or so at all.
Then you don't need CRLF in the worktree at all, as Eclipse handle
LF well.

and in this case you should be able to set
git config core.autocrlf input
on all repos, just in case someone sneaks in a CRLF somewhere.
(And after the normalizing of course)

https://www.kernel.org/pub/software/scm/git/docs/git-config.html

(and don't ask me if Egit supports that)

> 
> 
> $ git status
> # On branch master
> #
> nothing to commit (working directory clean)
> 
> $ file master/settings.gradle
> master/settings.gradle: ASCII text, with CRLF line terminators
That is under msysgit ?
(Side note: Msysgit is called Git for Windows these days)
> 
> $ dos2unix.exe master/settings.gradle
Is this under Msysgit ?
> dos2unix: converting file master/settings.gradle to Unix format ...
> 
> $ git status
> # On branch master
> #
> # Changes not staged for commit:
> #   (use "git add <file>..." to update what will be committed)
> #   (use "git checkout -- <file>..." to discard changes in working directory)
> #
> #       modified:   master/settings.gradle
> #
> no changes added to commit (use "git add" and/or "git commit -a")
> 
> $ git diff
> fatal: LF would be replaced by CRLF in master/settings.gradle
That's interesting.

What does 
git config -l | grep core
give ?