Rebasing commit from one parent onto another

The base you chose for the rebase is wrong and should be 81761ff instead of e5cb9b8. I would suggest you to do an interactive rebase and use --rebase-merges instead of --preserve-merges. So the command should be:

git rebase -ir --onto 1a92e84 81761ff master

Now, Git will probably produce one additional merge commit. To avoid that and to produce your desired outcome, you should adjust the todo-list to something like:

label onto
pick e5cb9b8 Adds support for removing parts on ReactorCells
label new
reset onto
merge -C ca230d8 new
pick 45a0a21 #17 Updates README.md
# Remaining commits...

In the todo-list, label can be used to mark the current commit (HEAD), and reset can be used to set the HEAD to some commit/label. merge is obviously used to produce a merge commit, -C makes the merge use the same commit message as the original merge commit.

This is quite advanced and really not needed for most users and use cases, so please consider man git-rebase, section Rebase Merges (or the online version here) for more in depth information. The example there is actually quite similar to your situation.

If you go with git rebase -ir, do so with Git 2.25 (Q1 2020).

A label used in the todo list that are generated by "git rebase --rebase-merges" is used as a part of a refname; the logic to come up with the label has been tightened to avoid names that cannot be used as such.

See commit cd55222 (17 Nov 2019) by Matthew Rogers (soniqua).
See commit 867bc1d (17 Nov 2019) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit 917d0d6, 05 Dec 2019)}

rebase -r: let label generate safer labels

^{Signed-off-by: Matthew Rogers
Signed-off-by: Johannes Schindelin}

The label todo command in interactive rebases creates temporary refs in the refs/rewritten/ namespace. These refs are stored as loose refs, i.e. as files in .git/refs/rewritten/, therefore they have to conform with file name limitations on the current filesystem in addition to the accepted ref format.

This poses a problem in particular on NTFS/FAT, where e.g. the colon, double-quote and pipe characters are disallowed as part of a file name.

Let's safeguard against this by replacing not only white-space characters by dashes, but all non-alpha-numeric ones.

However, we exempt non-ASCII UTF-8 characters from that, as it should be quite possible to reflect branch names such as ↯↯↯ in refs/file names.

---

And:

With Git 2.25 (Q1 2020), The logic to avoid duplicate label names generated by "git rebase --rebase-merges" forgot that the machinery itself uses "onto" as a label name, which must be avoided by auto-generated labels, which has been corrected.

See commit e02058a (18 Nov 2019) by Doan Tran Cong Danh (congdanhqx-zz).
^{(Merged by Junio C Hamano -- gitster -- in commit 995b1b1, 05 Dec 2019)}

sequencer: handle rebase-merges for "onto" message

^{Signed-off-by: Doan Tran Cong Danh
Acked-by: Johannes Schindelin}

In order to work correctly, git rebase --rebase-merges needs to make initial todo list with unique labels.

Those unique labels is being handled by employing a hashmap and appending an unique number if any duplicate is found.

But, we forget that beside those labels for side branches, we also have a special label onto for our so-called new-base.

In a special case that any of those labels for side branches named `onto', git will run into trouble.

Correct it.