Race condition with git-status and git-rebase

Hi,

Since I don't know how to fix it, this is my bug report:

git-status reads the index file then holds the `index.lock', it writes the updated index in `index.lock' and renames the `index.lock' to `index', but if it used with git-rebase then there is a (rare) race condition.

I reproduce this at my work under the following conditions:
1) The repository is very big
2) I can reproduce it only in Windows. I can not reproduce it in Linux
   (my Linux machine has faster CPU and SSD drive.)

I saw this race condition at my coworkers when they use two instances (in the same repository) of Git-Extensions GUI, and when they use one instance of Git-Extensions and at the same time they rebase from terminal. This race condition happens because Git-Extensions monitors the directory of the repository and when a file is accessed it calls git-status.

Since I can not share the repository, I decided to trace down the problem. I came up with the following:

process A calls git-rebase process A applies the 1st commit process B calls git-status process B calls read_cache() (status_init_config() -> gitmodules_config() -> read_cache()) process A applies the 2nd commit process B holds the index.lock process B writes back the old index (the one that was read from read_cache()) process A applies the 3rd commit (now the 3rd commit contains also a revert of the 2nd)

The content of the files of the working directory is correct (i.e. as it should be if the race condition didn't happen). But git-status shows that the files of the 2nd commit are modified, the git-diff show the exact patch of the 2nd commit.

So, in this case process B must avoid calling write_index(). Maybe something is missing from update_index_if_able()? Maybe git should check the state before proceeding to write_index() (for example that we are in rebase)?

Something else that I noticed is that when the race condition happens the istate->cache_changed is 0 and has_racy_timestamp(istate) is 1, so the if statement in update_index_if_able() continues to write_index().

I didn't check if there are other similar race conditions.

Regards, Yiannis.

PS: I tried to move hold_locked_index() above status_init_config() but
this cause other problems.