1

My team has had a lot of trouble with GIT lately because the 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?

user1326955
  • 11
  • 2
  • In the third paragraph, I meant I have seen a repository go from nothing to commit to a hosed state from running git pull and it aborting without going into a MERGING state. – user1326955 Apr 12 '12 at 14:38
  • I've been having similar problems and so far one of the only ways I can temporarily "fix" the problem is to make a backup of my present working local copy elsewhere, then delete everything (including the .git directory) in the first directory. Then I tell git to create a new repository and can then `pull` from the master repository again. – stealthyninja Jun 28 '12 at 17:28

1 Answers1

1

"git pull" is the same as "git fetch + git merge". So, when git abort, it is on a merge.

When git try to merge a branch, it does it "as far as possible". The files that can be merged are merged, and the files that cannot be merged automatically are left in a state "both modified". The developer has to check the files manually to complete the merge.

If you prefer a clean state after an incomplete "git pull" (or "git merge"), you can easily come back to your last revision before the merge, with the command:

git reset --hard my_local_branch

In your case, I suppose that "my_local_branch" is "master".

Benoit Courtine
  • 7,014
  • 31
  • 42
  • This is the part of GIT that I understand pretty well. This does not answer the questions I asked though. This will remove any uncommitted local modifications you have. This will not get you into a clean state either as you need to run an additional command to remove the untracked files (which will cause the next pull to abort). – user1326955 Apr 12 '12 at 14:33