Git merge conflicts when no changes done

Question

I've cloned a repo and then, after a few hours, I've made 'git pull'. However merge conflicts appeared and I don't understand why because I haven't made any change into cloned repo.

git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean


git pull
remote: Counting objects: 6211, done.
remote: Compressing objects: 100% (849/849), done.
remote: Total 3237 (delta 2756), reused 2846 (delta 2371)
Receiving objects: 100% (3237/3237), 865.51 KiB | 152.00 KiB/s, done.
Resolving deltas: 100% (2756/2756), completed with 867 local objects.
From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
 + 76c2c6d...4d046e9 master     -> origin/master  (forced update)
 + 1e13928...003e6ba akpm       -> origin/akpm  (forced update)
 + 9d1d11d...8bcfe39 akpm-base  -> origin/akpm-base  (forced update)
   37504a3b..8ba4caf stable     -> origin/stable
 * [new tag]         next-20140918 -> next-20140918
Performing inexact rename detection: 100% (318500/318500), done.
Auto-merging tools/testing/selftests/rcutorture/doc/TREE_RCU-kconfig.txt
CONFLICT (content): Merge conflict in tools/testing/selftests/rcutorture/doc/TREE_RCU-kconfig.txt
Auto-merging tools/testing/selftests/rcutorture/configs/rcu/TREE03
Auto-merging localversion-next
CONFLICT (add/add): Merge conflict in localversion-next
Auto-merging kernel/rcu/tree.c
CONFLICT (content): Merge conflict in kernel/rcu/tree.c
Auto-merging drivers/target/target_core_fabric_configfs.c
CONFLICT (content): Merge conflict in drivers/target/target_core_fabric_configfs.c
Auto-merging drivers/target/iscsi/iscsi_target_util.c
Auto-merging drivers/hwmon/Kconfig
Auto-merging drivers/gpu/drm/i915/intel_ringbuffer.c
Auto-merging drivers/gpu/drm/i915/intel_drv.h
Auto-merging drivers/gpu/drm/i915/intel_dp.c
Auto-merging drivers/gpu/drm/i915/intel_display.c
Auto-merging drivers/gpu/drm/i915/i915_gem.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem.c
Auto-merging drivers/clk/rockchip/clk-rk3288.c
Auto-merging arch/mips/include/asm/topology.h
Auto-merging arch/m68k/coldfire/m54xx.c
Auto-merging Next/quilt-import.log
CONFLICT (add/add): Merge conflict in Next/quilt-import.log
Auto-merging Next/merge.log
CONFLICT (add/add): Merge conflict in Next/merge.log
Auto-merging Next/SHA1s
CONFLICT (add/add): Merge conflict in Next/SHA1s
warning: inexact rename detection was skipped due to too many files.
warning: you may want to set your merge.renamelimit variable to at least 5040 and retry the command.
Automatic merge failed; fix conflicts and then commit the result.

git status
On branch master
Your branch and 'origin/master' have diverged,
and have 236 and 347 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

You have unmerged paths.
  (fix conflicts and run "git commit")

Changes to be committed:
    ...

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both added:      Next/SHA1s
    both added:      Next/merge.log
    both added:      Next/quilt-import.log
    both modified:   drivers/gpu/drm/i915/i915_gem.c
    both modified:   drivers/target/target_core_fabric_configfs.c
    both modified:   kernel/rcu/tree.c
    both added:      localversion-next
    both modified:   tools/testing/selftests/rcutorture/doc/TREE_RCU-kconfig.txt

Answer 1

First of all a bit of pre-caution I'm using on a daily basis...

I learned to use git merge --ff-only when I don't expect any actual merge. I see it's also possible to use git pull --ff-only but more often I use git pull --rebase so it doesn't create any merge commits but instead replays my local changes (if any) on top of upstream. I can't help with the explanation, though, as I don't know the rules for linux-next.

The only reason to have a merge conflict is merging to divergent branches. In case your branch wasn't changed, one would expect a clean fast-forward merge. The only explanation fitting your description is that the remote no longer includes your commit in its history and that means the upstream has a rewritten history. That's quite common in some workflows where the published branch is just a pointer to the latest commit of a larger set of changes. I don't have specific information for linux-next, though.

Danger zone: When this situation arises, you can get the upstream data using git fetch and then update your branch ref using git reset --hard origin/master (substitute origin and master with actual remote and branch names). But be sure there aren't any changes that you would like to save as this is a destructive operation.

Answer 2

In addition to Pavel's comments, make sure you don't have a committed change you haven't pushed upstream yet. In that case if you see you have 0 files that need to be committed (and are low on sleep perhaps) you might be a little puzzled when it wants to start merging.