Community
Participate
Working Groups
How to reproduce: 1) Have your C files indexed. 2) In Git switch to another branch. Expected result: The indexer has up-to-date information to not trigger the indexing process again. Actual result: Eclipse triggers another indexer run. This is time consuming and blocks user activities. This foils Git's benefit of switching between branches easily and fast work. Perhaps it could be avoided if the indexer also stores information about the branch where the indexed resource resides and is only updated on clone, pull and fetch operations.
I don't know anything about the indexer but since you switch git branches all code could change, so the indexer has to be run again, no?
(In reply to Marc Khouzam from comment #1) > I don't know anything about the indexer but since you switch git branches > all code could change, so the indexer has to be run again, no? I wouldn't say that all code changes, usually it's only a bit because the branches differ in details. However, in the current state another index run is too time consuming for the user to work fluently. I propose to include branch information into the stored code location to prevent Eclipse/CDT from reindexing a lot. If the user switches to another branch which is already indexed the indexer would not have to be run again.
If the SCM team provider is done right, we should only get deltas for the files that have changed. The deltas would restrict what gets reindexed to only those things that do. I haven't tested this on large projects enough to know whether that's true or not.
I just tried again, but unfortunately this doesn't happen. The indexer grabs all sources, no matter whether changed or not.