|Re: [jgit-dev] Quick question about WorkingTreeIterator::contentCheck|
The API should be unchanged. But I don't know Netbeans; if it somehow requires
specifically 5.5.0, upgrading only JGit might not work.
It's a bit more complicated than that. It may have an effect on determining
whether a file is changed because it makes JGit perform more content checks.
If then crlf settings are different, JGit would report differences where it formerly
didn't because it didn't even check the contents because timestamps matched.
One source of different crlf settings on Windows is that git-for-windows for some
time used an extra git config file in a non-standard location at
%PROGRAMDATA%\Git\config. That file usually contained core.autocrlf = true,
but since it was a non-standard location, other git tools (like JGit) missed it.
Support for that extra config file was therefore removed in git-for-windows again;
If that is the cause of the changed files you see reported, add core.autocrlf = true
to the normal git config (global or repo-specific config). If all content-related config
settings are equal, then yes, the timestamp resolution problem should only be a
performance issue, albeit a major one since it effectively negates the benefits of
having a git index for the large majority of files.
Back to the top