threads / discuss / 30224

GIT pull

Subject: GIT pull

## tl;dr

5 messages between Apr 12, 2012 and Apr 12, 2012.

replies: 4people: 4as markdown or json

cvalusek· Apr 12, 2012, 14:47 UTC · lore

My apologies if this isn't the appropriate place to post this. We are using the windows port msysgit so I understand if I need to post over there first.

I have also posted this on stackoverflow. Here is a link to the question there:

http://stackoverflow.com/questions/10110401/why-doesnt-git-clean-up-when-aborting-a-merge-triggered-from-pulling-in-changes

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. I understand that without rebasing, you may be forced to resolve merge conflicts when you pull, but this is not what is happening though.

We are using gitolite. I am mainly using command line and have yet to run into these issues. The rest of the team is using the git-gui or in 1 case TortoiseGit.

git-gui version 0.13.GITGUI git version 1.7.8.msysgit.0 Tcl/Tk version 8.5.1 TortoiseGit 1.7.6.0

We are not working with branches as much as we could, but feel like this should be working. Why does GIT allow you to try to pull when it is going to train-wreck? Why does GIT not abort cleanly?

-- View this message in context: http://git.661346.n2.nabble.com/GIT-pull-tp7459655p7459655.html Sent from the git mailing list archive at Nabble.com.

Matthieu Moy· Apr 12, 2012, 15:03 UTC · re: cvalusek · lore

Re: GIT pull

cvalusek <clintv2@gmail.com> writes:

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

What do you mean by "terrible state"? What does "git status" say?

> In the past, I thought GIT would run some sort of check to identify
> these problems before it attempts the merge.

Git does check uncommited changes before merging. It allows the merge if the changes touch different files (i.e. if the merge is guaranteed not to touch the same files as the one for which you have uncommited changes).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Michael Witten· Apr 12, 2012, 15:07 UTC · re: Matthieu Moy · lore

Re: GIT pull

On Thu, Apr 12, 2012 at 15:03, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 16 quoted lines

> cvalusek <clintv2@gmail.com> writes:
>
>> 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.
>
> What do you mean by "terrible state"? What does "git status" say?
>
>> In the past, I thought GIT would run some sort of check to identify
>> these problems before it attempts the merge.
>
> Git does check uncommited changes before merging. It allows the merge if
> the changes touch different files (i.e. if the merge is guaranteed not
> to touch the same files as the one for which you have uncommited
> changes).

Also, if there *are* conflicts, then you should get an error that looks like the following:

  error: Your local changes to the following files would be
  overwritten by merge:
  	some-file.txt
  Please, commit your changes or stash them before you can merge.
  Aborting

Sincerely, Michael Witten

Johannes Sixt· Apr 12, 2012, 16:58 UTC · re: cvalusek · lore

Re: GIT pull

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

cvalusek· Apr 12, 2012, 17:29 UTC · re: cvalusek · lore

Re: GIT pull

Looks like it's the virus scan. I had this e-mail that I accidentally sent to Michael directly instead of the list:

I will see if I can build a script that reproduces the issue we are seeing.

We are starting to speculate about what is going on now. Maybe our virus scan is causing some git operation to fail in the middle of the merge.

The "terrible state" is a half-way applied merge.

-- View this message in context: http://git.661346.n2.nabble.com/GIT-pull-tp7459655p7460163.html Sent from the git mailing list archive at Nabble.com.