I’ve used interactive rebasing numerous times, but perhaps not in such a complex context as I did just now. I’m trying to correct a feature branch. This feature branch is meant to be merged to remote master via a pull request using a no-squash merge; however, there are many merge commits (from master) to this feature branch that we would like to get rid of (and instead do a single rebase on top of remote master prior to landing this pull request).

For clarity, the feature branch looks something like this

commit 1
commit 2
merge commit
commit 3
merge commit
commit 4
commit 5
merge commit
.........
commit 20

all the merge commits are from master to this branch. The goal is to remove all the merge commits and rebase commits 1..20 on top of master.

So I tried to do:

git fetch --all
git rebase -i origin/master --rebase-merges

but I cannot seem to resolve the conflicts correctly when it comes to the conflicts that say

(deleted by us) <some file path>

I read git rebase “deleted by us” and “deleted by them” and I think I grasp what us actually means here, but from my undertanding, neither us nor them deleted this file. For example, there was a file that was added years ago that showed up with deleted by us and that file was edited (but never removed) by commits 1..20, not by any commit on master since the file was added.

So I’m very confused why this is happening?

I would like to better understand this, but I realized that my interactive rebase approach may not be the cleanest approach here. I think what I could is start from a fresh branch crafted from master, cherry-pick over commits 1..20, and then either start a new pull request from this new branch or override the old branch with the new branch.