Re: Race condition with git-status and git-rebase

Yiannis Marangos writes: > process A calls git-rebase > process A applies the 1st commit > process B calls git-status > process B calls 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())

Re: Race condition with git-status and git-rebase

Maybe you will find it useful: this is one way that I use to manually debug the race condition (and it works in Linux): diff --git a/builtin/commit.c b/builtin/commit.c index d9550c5..c0511f6 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -1283,6 +1283,8 @@ int cmd_status(int argc, const

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