[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] speeding up re-indexing
|
Markus Duft skrev 2012-05-30 16.38:
On 05/30/2012 09:32 AM, Markus Duft wrote:
[snip]
phew. i traced some more, and i found out that neither mightBeRacilyClean() nor smudgeRacilyClean() are involved in smudging the index?!
i added printlns() there and everything looks ok - only one single file coming by, but 33000 smudged?!
and also DirCacheEntry#setLength is not hit. it is called with 0 for every empty file, but not a single other one. for me it does not look like jgit does something wrong "intentionally". maybe the field with the size is accidentally overwritten somewhere? it's not smudging related code that causes smudging here...
i'm out of ideas now - seems you guys have to take over the rest... can somebody reproduce the problem? just rebase a commit on another branch, and according to "git ls-files --debug -s | grep "size: 0" | wc -l" all tracked files are smudged.
And the changes
https://git.eclipse.org/r/#/c/6137/
https://git.eclipse.org/r/#/c/6138/
make the problem go away. index is not smudged anymore after rebase (only a single file, but thats not so dramatic, and probably ok). Not sure whether they just "hide" a underlying problem or really fix it...
I think this is the solution, though it may still be improved. E.g. we might want to rewrite the index when not intending to write
if we discover there are a large number of smudged entries when reading (as C git does).
-- robin
