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 -- 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