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
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
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() ->
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 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.
PS: I tried to move hold_locked_index() above status_init_config() but
this cause other problems.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html