Re: [jgit-dev] Quick question about WorkingTreeIterator::contentCheck

[Thomas Wolf <thomas.wolf@xxxxxxxxxx>]

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.

[1] https://github.com/git-for-windows/git/commit/d8ab53dddb79b6aba12d4ea8934e0a55889e3fdf

Cheers,

  Thomas