'git pull' brings others' commits into my staging area during merge conflict

Question

So, I have faced this nasty problem quite often, and tried looking for any solutions online, but I am not sure if this is git\'s expected behavior or not.

Whenever I

Answer 1

The staged files you are seeing are the results of all the changes between the last time you synchronised your local branch with the remote branch (I guess master as you do not mention it).

Git pull has 'fetched' the changes since you last pulled, then it tries to merge this local copy of the remote branch into your local branch. It then hit a conflict in one of the changed files.

So it has to stop in the middle of the merge to ask you how to resolve the conflict to the one file.

So the other files are ready to merge, have been staged and would have been merged automatically if there hadn't been any other conflicts.

To complete the automatic merge, you need to a) resolve the conflict then b) hit commit to finish merging the other people's changes into your local branch. (Some GUIs automate the commit completion step after you click a "I've finished resolving" button)

You will also notice in the commit window of your GUI, there is a pre-fabricated merge message for the pending commit? It will say something like "merging origin/x into x... Conflicts: y". Once all the changed files can be added to the stage you are ready to complete this automatic commit which was paused.

So this sounds like expected behaviour to me, but you are just seeing "inside" one of git's internal processes.

Stashing shouldn't be necessary or involved here. Although some GUIs do auto-stash, git itself doesn't use stashing during a pull.

Note: you shouldn't have any changed files locally when you do a pull. (i.e. commit everything clean before doing any branch operations, is a good best practice) Having a GUI clean up your changed files is when auto-stash is useful, but it still has its complications when there are conflicts. i.e. you need to resolve the conflicts then remember to pop the stash afterwards. If you rely on the automation too much, it gets confusing when you have to complete the automated process you don't know about! So I'd recommend always keeping your working directory clean.

Answer 2

The default behaviour of git pull is to perform a fetch and then a merge. A merge is an actual, new, commit; normally this is resolved automatically so you see no staged changes. However, in the case of a conflict, the commit cannot be performed automatically, hence the visible staged changes.