On Tue, Feb 10, 2015 at 4:32 PM, Torsten Bögershausen <tboegi@xxxxxx> wrote: > On 2015-02-10 11.52, Piotr Krukowiecki wrote: >> >> 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. >> Cygwin git works ok. So I did not check how msysgit works yet. > > 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) Thanks, I'll have a look later if I have some free time. Since Cygwin's git is more recent I'd prefer to use it instead of "msys", unless there are some other advantages of msys version. >> 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. I meant that there are some actual changes in the file (not only whitespaces), but the line with the changes also has LF eol instead of CRLF, and the actual changes are now shown. That's what the examples below show. >> 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 ? Just an use case - if for some reason someone/something coverts the file to LF eol. Plus I think it would be better if empty commit was not done (since there are no actual changes besides LF<->CRLF). > 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. That's true, but I thought it'd be better to use native EOLs. The reasons: - new files will have initially CRLF (and will be converted to LF on first commit, but I think they will be left with CRLF in workspace even after commit), so workspace might have CRLF files anyway - some files are c# code/projects and are developer in VS, so they should probably have CRLF eols; not checked how VS will work yet. - some external tools might not work with non-native EOLs (not that I know of any specific tool we use - just a precaution) - when in Rome, do as Romans do, generally ;) > 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) I'm aware of that option, we might change to it - but I still don't see what's the advantage, except lack of CRLF<->LF conversion (that's a valid reason, but won't core.safecrlf help here?) >> $ 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) Nope - both repository and client was cygwin git. >> $ dos2unix.exe master/settings.gradle > Is this under Msysgit ? Cygwin. >> 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 ? core.autocrlf=true core.safecrlf=true core.eol=native core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true core.ignorecase=true Plus, "*.gradle text" in .gitattributes. As I wrote, it might be old Cygwin git - 1.7.9. Will try to update. -- Piotr Krukowiecki -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html