1

I did a git pull and it told me it couldn't auto-merge because there were a few conflicting changes that got made on the remote and local concurrently. I did a manual merge. What do I need to do next in order to complete my pull?

RELATED: git pull merges no files if any of the deltas are conflicted (need manual merge)

Community
  • 1
  • 1
amphibient
  • 29,770
  • 54
  • 146
  • 240

1 Answers1

3

git add the files you changed, and then commit. The message should be filled in automatically with conflict details and a summary.

Ry-
  • 218,210
  • 55
  • 464
  • 476
  • i thought the same but then I did a `git diff` on one of the files I changed and got nothing in return (as though there is no diff) – amphibient Dec 03 '13 at 15:39
  • the thing is, i don't want to commit them before I know i can build. but in order to do a build, i need all the other changes coming from the remote that are not conflicted – amphibient Dec 03 '13 at 15:41
  • @amphibient: `git pull` should have already applied those changes. And if you’ve already staged the file, run `git diff --staged` to find out what changed. – Ry- Dec 03 '13 at 15:43
  • it did not. i am showing a bunch of files as "modified" but when i do a diff, i get nothing in return – amphibient Dec 03 '13 at 15:45
  • 1
    @amphibient: Did you try `git diff --staged`? Merging does also stage any changed files that didn’t conflict. – Ry- Dec 03 '13 at 15:47
  • OK... so that did return stuff. but it is showing files as modified whereas they are modified on the remote and not local. and i do not have those changes merged locally even though they are not conflicted. – amphibient Dec 03 '13 at 15:52
  • IOW, the four files i have just merged are showing as "modified" the same as the files that were change on the remote, i.e. they are in the same category, which is confusing. – amphibient Dec 03 '13 at 15:53
  • @amphibient: Like I said earlier, `git pull` applies non-conflicting changes. I think it has in your case. – Ry- Dec 03 '13 at 15:53
  • it didn't happen in my case. – amphibient Dec 03 '13 at 15:54
  • @amphibient: `git diff --staged` would seem to indicate otherwise, because it doesn’t know what state the remote’s in. Are you on the branch you think you’re on? Did you run anything (resets?) between `git pull` and `git add`/`git diff`? – Ry- Dec 03 '13 at 15:56
  • @amphibient: If the files that didn’t seem to get pulled show up in both staged and unstaged changes when you do `git status`, do a `git stash`, `git reset --hard HEAD` **(make sure to double-check `git status` and not lose anything here!)**, and `git stash pop`. – Ry- Dec 03 '13 at 15:58
  • i did that. all the changes from the remote are still showing as modified/deleted and are not merged. The files I merged manually and the changes from the remote are all lumped in the same category, which is not the way it should be – amphibient Dec 03 '13 at 16:02
  • @amphibient: Okay. Can you paste the output from `git status`, please? – Ry- Dec 03 '13 at 16:03
  • it's a lot but you can visualize that in the `# Changes to be committed` category there are a bunch of `modified/deleted` that are so on the remote, not on the local – amphibient Dec 03 '13 at 16:05
  • @amphibient: Hmm. `git status` doesn’t check from remotes as far as I know. That’s perplexing. So you’re sure that the same files don’t appear in both “to be committed” and “unstaged” sections? – Ry- Dec 03 '13 at 16:33
  • i know that but i did a `git pull`. i meant that what is in the local is what is on the remote but relative to what is actually in the working directory, it has not been merged. so the new (remote) version is in the local repo, working dir has not been merged but `git status` is showing that the working dir files have been modified – amphibient Dec 03 '13 at 16:36
  • i want to merge what's in the local to the disk but git is showing that i have modified the files that were actually modified on the remote and are now in local – amphibient Dec 03 '13 at 16:38
  • working with this thing is like walking through a minefield... i like the whole local branch concept and all and i'm sure there is a way to walk through the minefield safe but what are the chances? the tedium is overwhelming, i am sure it is a great version control system but someone needs to say there is an elephant in the room – amphibient Dec 03 '13 at 16:41
  • @amphibient: That really shouldn’t happen. In a Git repository, you have remotes, branches, staged changes, and working tree changes. `git add` and `git rm` stage a working tree change; `git commit` moves staged changes to a branch’s history. `git pull` fetches changes and merges them. If all changes can be merged automatically, that happens with a commit; if all changes can be fast-forwarded, that happens; otherwise, auto-merged changes are staged and put in the working directory, and conflicts are modified in the working directory. When you resolve the conflict, you do `git add` and commit. – Ry- Dec 03 '13 at 17:02
  • … so if you are absolutely sure the changes weren’t applied, try stashing, resetting the merge, and pulling again. – Ry- Dec 03 '13 at 17:03
  • @amphibient: Can you show a screenshot? (Maybe even with names replaced or something?) – Ry- Dec 03 '13 at 17:54
  • here is a related thread i just posted: http://stackoverflow.com/questions/20358933/git-pull-merges-no-files-if-any-of-the-delta-are-conflicted-need-manual-merge – amphibient Dec 03 '13 at 18:39