Bug 561877 - Unexpected CRLF conversion on clone
Summary: Unexpected CRLF conversion on clone
Status: RESOLVED FIXED
Alias: None
Product: JGit
Classification: Technology
Component: JGit (show other bugs)
Version: 5.7   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: 5.8   Edit
Assignee: Thomas Wolf CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-07 12:57 EDT by Rice Bauer CLA
Modified: 2020-05-22 18:27 EDT (History)
4 users (show)

See Also:


Attachments
zipped Git repo which shows the bug (13.05 KB, application/x-zip-compressed)
2020-04-07 12:57 EDT, Rice Bauer CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rice Bauer CLA 2020-04-07 12:57:43 EDT
Created attachment 282374 [details]
zipped Git repo which shows the bug

Hi,

I'm on a Windows 10 machine with Eclipse 2020-03 and a .gitattributes with only this line:
* text=auto

My gitconfig (system level) contains the following entry:
[core]
	autocrlf = input

Inside my repo, the text files contain LF line endings.

So, what I'd expect is that no line ending conversion happens on checkout and clone. That is also what Git for Windows does and what I read from here: https://git-scm.com/docs/gitattributes.
And for the checkout command, this is also what Eclipse does. So if I checkout an old commit that doesn't contain a certain text file and then checkout the latest commit again, I got LFs in the working directory.

However, if I perform a clone from the Eclipse (either via the File menu or the Git repo view), my text files are checked out with CRLF line endings.

I attached a zipped (non-bare) Git repo that shows this behaviour on master branch. For convenience, I also included a branch called "no-gitattributes" that does not include a gitattributes and clones with LF line endings.
You can use this as a remote repo to clone from via the file protocol.

See also my forum post here:
https://www.eclipse.org/forums/index.php/t/1103214/

Best regards
Rcie
Comment 1 Thomas Wolf CLA 2020-04-07 14:54:52 EDT
Just found it. And we can even test this on Linux/Mac because of the nature of the bug :-)

The problem is that JGit does not ignore the core.eol setting (which defaults to native, i.e. CR-LF on Windows) when core.autocrlf = input. See last sentence at [1]: "Note that this value is ignored if core.autocrlf is set to true OR INPUT." (Emphasis added.) 

This gives us actually a way to test this on non-Windows: we just have to set core.eol=crlf in addition to core.autocrlf=input. Then the bug reproduces.

This explains why JGit converts. It doesn't explain why it wouldn't convert on plain check-out, though. For me it does also produce CR-LF on checkout if I set core.autocrlf=input and core.eol=crlf.

I'll fix this tomorrow; it's a one-liner (plus a test case).

[1] https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreeol
Comment 2 Eclipse Genie CLA 2020-04-07 18:28:16 EDT
New Gerrit change created: https://git.eclipse.org/r/160622
Comment 3 Eclipse Genie CLA 2020-05-22 18:26:21 EDT
Gerrit change https://git.eclipse.org/r/160622 was merged to [master].
Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=3dbd1f2fe70f6f0ca25ad4278cb976e0d2ddb65a