git log reveals the following:
commit 1abcd[...]
Author: [...]
Date: [...]
[Useful commit]
commit 2abcd[...]
Author: [...]
Date: [...]
Merge branch [...] of [etc. etc.]
commit 3abcd[...]
Author: [...]
Date: [...]
[Useful commit]
That merge commit is useless to me - it doesn't represent a meaningful state of the branch and was generated from a remote pull, so I have the real commits of the remote history - no need for a commit to mark the fact that I pulled. I would like to squash this merge commit. My usual technique for doing a squash is:
git rebase --interactive HEAD~2 (or however far back I need to go)
And then I would squash it into a neighboring commit. I do this some times if for example I make a commit, realize I missed a tiny important detail (single file, or hadn't changed a line in one of the files), and do another commit that's basically just a quick oops. That way when I push my changes back to the remote, everything is nice and clean and tells a cohesive narrative.
However, in this case, when I run the git rebase ... command, commit 2abcd doesn't appear! It seems to skip right over 2abcd and instead displays 1abcd and 3abcd. Is there something special about a merge commit that prevents it from being appearing in git rebase --interactive? What other technique could I use to squash that merge commit?
UPDATE per @Cupcake's request:
The output of git log --graph --oneline --decorate looks like this:
* 1abcd (useful commit)
* 2abcd (merge)
| \ <-- from remote
| * 3abcd (useful commit)
| |
Helpful?
Git offers a new way using --rebase-merges :
Before --rebase-merges I get 6 conflicts with my specific case.
git rebase -i --rebase-merges origin/master
And you may see something like :
label onto
reset 4127388 # Formatting
pick 87da5b5 feat: add something
pick 8fcdff4 feat: add ..
merge -C 80784fe onto # Merge remote-tracking branch 'origin/master' into a-branch-name
pick 3d9fec7 add unit tests