Re: GIT pull

From: Johannes Sixt <j6t@kdbg.org>
Date: Apr 12, 2012, 16:58 UTC
Message-ID: <4F8709CA.6080102@kdbg.org>
In-Reply-To: <1334242077960-7459655.post@n2.nabble.com>

Am 12.04.2012 16:47, schrieb cvalusek:

Show 11 quoted lines

> 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