Possible race condition with git-rebase + .git/index.lock

Hi there,

I've been bit by this bug many times, and always forget to report it here, but this time I finally remembered.

The scenario is this:

- I have a local repository which tracks the upstream of the project.

- I have 120+ local commits.

- Every week or so, I have to rebase my local commits on top of
  upstream's origin/master.

The workflow is simple:

  # git fetch origin && git rebase origin/master

This works without problems most of the time (well, usually there are conflicts and all, but that's a burden I have to carry). However, sometimes I notice that git fails with:

  # git rebase origin/master
  ...
  Applying: commitX
  Applying: commitY
  Applying: commitZ
  fatal: Unable to create '/home/xyz/dir1/dir2/.git/index.lock': File exists.

The first thing I did was to check whether the index.lock file existed, but it doesn't.

I also I thought it might have something to do with "commitZ", but after I ran "git rebase --abort" and tried rebasing again, I noticed that it would stop at another commit.

This seems like a race condition, but after inspecting builtin/rebase.c it doesn't seem like the "git am" commands are run in parallel (and it wouldn't make sense if they did, anyway).

I tried using GIT_TRACE, but haven't seen any useful information in the logs. I tried using the "next" branch, and found that the problem exists there as well. I wonder if anyone else has seen this problem.

Thanks,