Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] Quick question about WorkingTreeIterator::contentCheck

On 11 Mar 2020, at 09:28, Peter Hull <peterhull90@xxxxxxxxx> wrote:

On Tue, 10 Mar 2020 at 22:01, Thomas Wolf <thomas.wolf@xxxxxxxxxx> wrote:
Which JGit version?
I assume that replacing 5.5.0 -> 5.5.1 would not require any changes
to the calling code?

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.

However, this should be a performance change shouldn't it, files
should still be marked correctly even if jgit has to go through the
slower route of checking file contents?

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;
see [1].

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