Subject: Re: GIT pull

From: Johannes Sixt <[email-masked]>
Date: Thu, 12 Apr 2012 18:58:50 +0200

Am 12.04.2012 16:47, schrieb cvalusek:
> My team has had a lot of trouble with GIT lately because of aborted pull
> commands.
> 
> If a user has local modifications not on the index and does a pull, I have
> seen git attempt to start applying the merge to master and abort. The whole
> checkout is then left in a terrible state that is nearly unrecoverable. In
> the past, I thought GIT would run some sort of check to identify these
> problems before it attempts the merge.
> 
> Even with a clean state (nothing to commit), I have seen the same thing
> randomly happen at least once.

As others pointed out, this should not happen. That leaves one
possibility: You are on Windows, and you very likely have one or more of

- a virus scanner
- an IDE

running. It can happen that one of these programs happen to look at a
file at the same moment when git is trying to remove or rename the file.
This fails because on Windows a file that is open cannot be removed or
renamed. In this situation, the merge/checkout is aborted in the middle
and leaves a mess behind.

There's not a lot that can be done about it. I thought we have some
counter measures in our compatibility layer (e.g., retry the removal if
the first attempt fails due to permissions), but I have seen this happen
nevertheless. I haven't tried tracking it down because it happens so
rarely for me, and it didn't hurt *too* much so far.

-- Hannes