Hello git community,
I'd like to add a new feature in git-rebase: --undo-skip.
But first, I'd like to consult with the experts if it would be
beneficial for the project and if my line of tought is correct.
Imagine that you are working on a feature for a long time, but there
are multiple bug fixes happening at `master` branch at the same time.
After lots of commits on both ends, you decide to rebase your changes
on top of the current `master` branch.
After lots of conflict resolution steps, you mistakenly call
`git-rebase --skip` instead of `git-rebase --continue`, thus losing a
commit of your work, and possibly inserting bugs in your project.
The only solution for this right now would be to abort the current
rebase and start over.
It seems that a feature like this have been requested once on the mail list .
I propose the existence of --undo-skip on git-rebase's `$action` domain.
How I fixed it when that happened with me was (just after running the
1. I figured I was making a rebase that used `git-am` as a backend.
2. In the rebase-apply directory I searched for the patch file with
the change I just skipped.
3. Found the `rebase-apply/next` file.
4. Wrote the number of the patch I skipped - 1 in rebase-apply/next.
5. run `git rebase --skip` again on the repository.
This made the lost patch appear again and I could `--continue` it this time.
I propose the addition of an action `--undo-skip`, that could be
called only after a wrongfully called `--skip`.
`git rebase --undo-skip`.
I would implemented it to do programatically what I did by hand when
that happened with me.
Here are my questions for you:
1. Would this be beneficial for the users?
2. For `rebase--am`, I would need to change `git-rebase--am.sh` file, correct?
3. Can I assume `builtin/am.c` will always store its information on
`$state_dir/next` and `$state_dir/$patchnumbers`?
4. How hard would it be to add that logic for `rebase--interactive`
and `rebase--merge` backends?
Also, a little unrelated with this issue:
5. What happened to the rewrite of rebase in C ? I couldn't find
any information after 2016.