Re: EOL handling (EGit/svn/Windows)
From: Torsten Bögershausen <hidden>
Date: 2016-06-15 23:03:47
On 2015-02-10 11.52, Piotr Krukowiecki wrote:
On Tue, Feb 10, 2015 at 6:49 AM, Torsten Bögershausen [off-list ref] wrote:quoted
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.quoted
How many people are there involved, how many on Windows, how many on Linux ?Less than 10 actively, most on Windows.quoted
Do you want to commit to svn, or is this a one-time conversion ?One-time.quoted
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=342372quoted
add that to the repo, do the normalization and push. A line like this: * text=auto is the easiest way.I'm trying it.quoted
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 :(quoted
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 ?