Please help provide clarity on git rebase internals

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