Hi all, TLDR; I am seeing merge conflicts when rebasing even though applying them to HEAD of target branch should work. Can you please upgrade my understanding so I understand. My understanding is that rebasing branch B onto branch A unrolls all of branch B's commits and then "reduces" them onto the HEAD of branch A. For example, I took featureA branch from develop three days ago. develop subsequently had commits #d1, #d2 and #d3. featureA also had #f1 and #f2 and in terms of time they are all intermingled. My understanding of rebase is that after issuing "git fetch; git rebase origin/develop" in featureA branch a git log should show #f2, #f1, #d3, #d2, #d1. I am seeing this, but sometimes I see something I can't explain and that is a merge conflict as if git was doing a merge rather than a rebase. For example, let's imagine that #f1 removed fileA, some time later #d1 added a line to that file. If I was doing a merge then of course this should be a conflict, however applying #f1 to develop HEAD should work even if fileA has changed (i.e. #f1 removes the updated fileA). As it is I am frequently running into merge conflicts in this manner when it *appears* git is applying a patch from featureA onto develop _as it was then the patch was made_. I am also seeing merge conflicts that occur between commits in the develop branch itself as well, which I assumed would be effectively read-only. In terms of functional programming I thought rebase was a pure reduce of a sequence of patches from featureA branch onto HEAD. I have no idea what git is doing internally, and if I am confident of anything it is almost certainly that the bug is in my understanding :). What am I missing? Thanks, Col -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html