git log
reveals the following:
commit 1abcd[...]
Author: [...]
Date: [...]
[Useful commit]
commit 2abcd[...]
Author: [...]
Date: [...]
Me
--preserve-merges
Ok, so I'm not exactly sure what would happen if you tried to squash a merge commit using an interactive rebase with --preserve-merges
...but this is how I would remove the merge commit in your case and make your history linear:
Rebase everything before the merge commit on top of the remote branch.
Cherry-pick or rebase everything after the merge commit on top of the previously rebased commits.
So in terms of commands, that would look something like this:
# Reset to commit before merge commit
git reset --hard <merge>^
# Rebase onto the remote branch
git rebase <remote>/<branch>
# Cherry-pick the last commit
git cherry-pick 1abcd
# Leave a temporary branch at your current commit
git branch temp
# Reset to commit before merge commit
git reset --hard <merge>^
# Rebase onto the remote branch
git rebase <remote>/<branch>
# Cherry-pick the last commits using a commit range.
# The start of the range is exclusive (not included)
git cherry-pick <merge>..temp
# Alternatively to the cherry-pick above, you can instead rebase everything
# from the merge commit to the tip of the temp branch onto the other
# newly rebased commits.
#
# You can also use --preserve-merges to preserve merge commits following
# the first merge commit that you want to get rid of...but if there were
# any conflicts in those merge commits, you'll need to re-resolve them again.
git rebase --preserve-merges --onto <currentBranch> <merge> temp
# These next steps are only necessary if you did the rebase above,
# instead of using the cherry-pick range.
#
# Fast-forward your previous branch and delete temp
git checkout <previousBranch>
git merge temp
git branch -d temp
Official Linux Kernel git-cherry-pick(1) Manual Page
Official Linux Kernel git-rebase(1) Manual Page