|EGit (JGit) incorrectly detects modifications if autocrlf is changed after repo creation [message #1064196]
||Tue, 18 June 2013 08:21
| Vadim Dmitriev
Registered: July 2009
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 :
"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!
Powered by FUDForum
. Page generated in 0.01768 seconds