Git merge conflicts when no changes done

ぃ、小莉子 提交于 2019-12-04 03:26:06

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.

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.

What I did to resolve this issue was to temporarily switch to a different branch, delete (locally) the branch with the merge conflicts, then get the branch again.

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!