Re: git-rebase --undo-skip proposal

[Stefan Beller <sbeller@google.com>]

On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava <psiidium@gmail.com> wrote:
> 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 [1].
>
> 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
> wrong skip):
>
> 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 think this could also be done with "git rebase --edit-todo", which brings
up the right file in your editor.

> 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?

I guess it is.

> 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?

cc'd Johannes who is currently working on revamping rebase.

>
> Also, a little unrelated with this issue:
> 5. What happened to the rewrite of rebase in C [2]? I couldn't find
> any information after 2016.
>
> [1] https://public-inbox.org/git/201311011522.44631.thomas@koch.ro/
> [2] https://public-inbox.org/git/1457779597-6918-1-git-send-email-pyokagan@gmail.com/

cc'd Paul Tan, maybe he recalls the situation.