Thread (6 messages) 6 messages, 2 authors, 2016-06-15

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=342372

quoted
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 ?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help