> You git rebase --interactive onto master, picking only commit C.
So during an interactive rebase you drop one commit, and pick the other, then are upset at git for dropping your commit? It did exactly what you asked of it.
This would have easily been avoided if you had branched off your feature branch into a new one and did the interactive rebase there. Your old feature branch is still present, which you could rebase interactively, or drop HEAD so you only have the other commit, or whatever other thing to meet its needs.
Sure, I know now exactly what happened, and what I should have done in order to avoid it. My point here is that "Git repo is immutable and cannot lose data" is a lie, and people who believe it (like I did at the time -- hey, if anything breaks on rebase, I can always git reflog and reset to good state, right?) will have a bad time at some point down the line, so it's better to stop this lie from spreading.
So during an interactive rebase you drop one commit, and pick the other, then are upset at git for dropping your commit? It did exactly what you asked of it.
This would have easily been avoided if you had branched off your feature branch into a new one and did the interactive rebase there. Your old feature branch is still present, which you could rebase interactively, or drop HEAD so you only have the other commit, or whatever other thing to meet its needs.