Git merge conflicts when no changes done

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.

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.