[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jgit-dev] Modification status
|
IndexDiff is optimized heavily for performance, that's one reason why
looks more complicated then most people would expect. We want to avoid
reading the content of the working tree files wherever we can. In a
repo with 10000 files beeing forced to read 10000 file system contents
just because EGit wants to update the decorators in the graphical
presentation of the project would kill our performance.
IndexDiff computes where we have differences between git's index, a
given tree (most of the time that's HEAD) and your working tree files.
It should only compute where there are differences (e.g. on file
a/b.txt between index and working tree) but should not compute the
differences inside the file. Like "git status".
Like "git status" the result can be complex. We have three different
states of the same file and this leads to a lot of possible
situations. E.g. what's in the index can differ from HEAD and whats in
the working tree can differ from HEAD and INDEX. "git status" would
mention the same path twice in such cases. IndexDiff can report the
same path in "getChanged()" and in "getModified()" to deal with this.
The HEAD could have a folder "/a/" and a file "/a/b.txt" while the
index has nothing for "/a" and your working tree contains simple file
"/a".
Back to your case. If you expect a path <xyz> to be returned by
IndexDiff.getModified() then "git status --short-- <xyz>" should list
something non-blank as second field of the output. See [1].
If this can't explain why you don't get anything from IndexDiff I
would set temporarily in the config of the repo the following values:
git config core.autocrlf false
git config core.filemode false
Then restart your use case. Does it help.
[1] http://git-scm.com/docs/git-status#_short_format
