I have a git repository that has two branches with unrelated history like this
A'
A - B - [...] - C
where the [...]-part is complicated (non-linear and many commits). Both the commits A and A' are very simple, consisting of a single (nearly identical) file and commit B consists in removing that file and starting from scratch. Now I try to do a
git rebase --rebase-merges --onto A' B C
expecting that it will give me
A' - B' - [...] - C'
where X' is X with changed parent. I thought this would be fully automatic except possibly when creating B'. Instead git comes up with strange conflicts (allegedly removed files) even in non-merge commits that it asks me to resolve manually, but also asks me to re-resolve every merge-conflict that every occurred in [...].
In principle I would just like git to produce a commit B' identical to B except that it has parent A' (and a different SHA of course) and iterate. Is that not possible?
[In case someone is wondering, why I am trying to do this: Overleaf has a restricted git implementation where I can't just use an existing git repository to initialize a project but rather have to create an empty project (my A') there and then transplant my existing project on top of it.]
Edit (summary of solution): As LeGEC points out the B should be an A in what I wrote. After that eftshift0's comment to LeGECs answer resolves the problem of having to redo the merges, except one has to add the restored files before --continueing the rebase to mark the conflict solved.
Try running:
git rebase --rebase-merges --onto A' A C
In the following command: git rebase --rebase-merges --onto A' B C, the B commit would be excluded from the rebase -- much like B doesn't show up in the range git log B..C.
Perhaps the unexpected merge conflicts you witness come from the missing B' in the rewritten history ?