EGit (JGit) incorrectly detects modifications if autocrlf is changed after repo creation [message #1064196] |
Tue, 18 June 2013 08:21 |
Vadim Dmitriev Messages: 74 Registered: July 2009 |
Member |
|
|
Hello. My name is Vadim and I have a problem!
This problem actually is about staging view, file modifications and how JGit and command line git handle line-ending differences. AFAIR, it all began when I committed bunch of files with core.autocrlf=false, but now I try to use core.autocrlf=true whenever I can. If I touch the file in the working copy, JGit always indicates that the file is modified (if I revert core.autocrlf back to false, file is correctly considered unchanged). In contrast, command line git handles this case and correctly reports no modifications with core.autocrlf both true or false.
I already wrote what I have found on so far on the issue here [1]:
"Originally file was committed with hash computed for win-style line endings several months ago. If I touch the file now its hash is recomputed for "canonicalized" unix-style endings.
I don't know why exactly: either something changed in jgit or I altered repository config. However, as a result org.eclipse.jgit.treewalk.WorkingTreeIterator#contentCheck(DirCacheEntry) sees different hashes and marks file as changed. Console git works around this somehow, but jgit doesn't."
One day I found filed bug regarding this problem, but forgot to bookmark it. Now I can't find it neither through bugzilla search, nor by google Will be grateful if someone will point me to that bug.
If it happens that developers never heard of this problem, I will create a new entry, but I want to avoid duplicates if possible.
Thanks in advance!
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=392382#c4
|
|
|
|
Powered by
FUDForum. Page generated in 0.04426 seconds