| Re: [egit-dev] re-indexing running for nothing |
|
I guess you need core.autocrlf to be true, or? If you have set it could you do me a favor and test again with temporarily set core.autocrlf set to false for all repos opened in eclipse? I would: - Stop eclipse - Set the property core.autocrlf=false in all repos being opened in eclipse - Go to the root of each repo and call a “git status” The reason why I ask: Ideally it shouldn’t matter too much how often we reindex. If index is set correctly and has only clean (unsmudged) entries we should never compute SHA1s during reindex. EGit/JGit
should detect from the index and its lastmodification-time info that all files are clean. We compute the SHA1’s only if the lastmodification of a file tells us it was really modified (unlikely in your case) or if a index entry is smudged (it’s length was intentionally
set to 0 to mark that this file can be racily clean. We can’t trust lastmodified+length and have to recomputed SHA1). And what I know is that when autocrlf is on then we always modify files in a checkout just before writing a new index leading to a lot of
smudged entries. All this is only for finding the reason why we compute SHA1s of versioned file. That’s no explanation why we compute SHA1’s on non-versioned/ignored files. Ciao Chris |