Race condition with git-status and git-rebase

[Yiannis Marangos <yiannis.marangos@gmail.com>]

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.