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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html