Undoing git rebase mistakes - rebase

Question

I never had too much trouble with rebase, mainly because I tend to be more careful while committing regarding the amount of code and scope. But while working to merge some legacy projects changes with my peers, we had a major problem using a rebase-first approach (because of large sets of changes in commits). So this got me thinking about how to solve some of these problems that seem very common for this situation.
Ok now, please consider that I'm currently doing a rebase and I have applied half of my commits so far. I'm now applying this next commit and resolving some conflicts. I have three main questions:
1) How do I redo the rebase for this single wrongly merged file?
2) How do I redo the rebase for all files inside this commit I'm applying, if I made more the one mistake merging/ deleting or adding files?
3) How do I go back already applied commits in this rebase if I realize I made a mistake merging a file or two that was already applied some commits back?
PS.: I'm aware of git reflog and the ORIG_HEAD pointer. I do want to make it work while preserving the git rebase operation state. I don't know if there is an easier way around this.

Answer 1

Ok.... just thinking..... I guess you might --abort the rebase operation, go back to the rebased revision that you would like to correct, and then run rebase again but specifying a new segment of revisions to apply. Let's suppose that you have branch A that was started from master..... it has 20 revisions. So.... you are already rebasing A~10..... and you just noticed that it's actually not correct... A~15 was not correctly rebased. So.... this is what I would do
git rebase --abort # stop rebase
git reflog # find the rebased revision of A~15 on top of master
git checkout rebased-revision-for-A~15
# correct the revision
git add .
git commit --amend --no-edit # correct the rebased revision
# continue with the process
git rebase --onto HEAD A~15 A
That way you can continue as you were doing.... only with a detour.

Answer 2

This is (a) a hard problem in general, and (b) shot through with personal preferences, which makes it really tough to have a good general solution.
The way to think about solving it is to remember that rebase copies commits. We need a way to establish some kind of user friendly mapping between multiple copies of commits.
That is, suppose we have:
O1--O2--O3 <-- branch#{1} (as originally developed with original commits)
/
...--M1--M2--M3--M4 <-- mainline
\ \
\ S1--S2 <-- HEAD (in middle of second rebase)
\
R1--R2--R3 <-- branch (after first rebase)
The mapping here is that O1, R1, and S1 are all somehow "equivalent", even if their patch IDs don't match and/or there's a mistake in R1 and/or S1. Similarly, O2, R2, and S2 are "equivalent" and O3 and R3 are "equivalent" (there is no S3).
Git does not offer a mechanism to go back to S1. You can fuss with S2 all you like, using git commit --amend to make an S2a whose parent is S1, but your only built in option is to keep going or abort entirely. If you keep going, eventually the name branch will be peeled off R3 and pasted onto S3, and branch#{1} becomes branch#{2}, with branch#{1} and ORIG_HEAD remembering R3.
Git also does not offer a solid mechanism to mark any of the O/R/S commits as "equivalent". The closest you get is git patch-id. And of course if you've used squash or fixup operations in an automatic rebase, what you really want something fancier, e.g., "R2 is equivalent to Ox squashed with Oy" or whatever.
You can use reflogs, or set a branch or tag name, to be able to recover the hash ID of commit S2 from which you can find S1. That allows you to make your own rebase-like command that works by cherry-picking S1 and stopping for amend, then cherry-picking S2 and going on to cherry-pick R3. But you'll only know how to do this in general with an equivalence mapping.
How to proceed from here is up to you: you'll be building your own tools. You can use git rev-list to get the hash IDs of selected commits. Just be sure that if there are branch-and-merge operations within the sequence of commits to be cherry-picked, you have used --topo-order to get consistent ordering.

Answer 3

First of all: READ THE ENTIRE ANSWER AND UNDERSTAND IT BEFORE RUNNING THE COMMANDS, as there is a git reset --hard on middle of the answer otherwise YOU MAY LOSE YOUR WORK
What I usually do is
Create patches for each commit that you want to pick. Suppose that you're 3 commits of master I would do something like this
# Generate patch for the committed code so we don't lose code
git format-patch -3
Check the patches and that they have the code that you expect. The
above command will generate three files 0001-something.patch 0002-something.patch and 0003-something.patch where something is the
commit message for each commit. With this code living on the filesystem
I'm sure that I will not lose it. Then I do a hard reset.
** THIS IS DANGEROUS, MAKE SURE THAT THE PATCHES ARE OKAY **
git reset --hard origin/master
Then I apply the patches
git apply 0001-something.patch
git apply 0002-something.patch
git apply 0003-something.patch
A better solution would be to checkout to master commit and cherry pick your commits, but at this point I don't know to to override my branch's commits, if some one knows how to do it it would be better.
Some time is easier to create another branch and cherry pick the right commits, but if you have a pull request already opened and if there is discussion on it you may want to keep the same branch and override the commits. I don't know how to do this with git checkout + git cherry-pick