On Wed, 14 Feb 2018, Psidium Guajava wrote:
> On 2018-02-13 18:42 GMT-02:00 Stefan Beller <sbel...@google.com> wrote:
> > On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava <psiid...@gmail.com>
> > wrote:
> > I think this could also be done with "git rebase --edit-todo", which brings
> > up the right file in your editor.
> Yeah that'd would only work if one started a rebase as a interactive
> one, not am or merge.
I agree that the original proposal was clearly for the non-interactive
rebase (it talked about .git/rebase-apply/).
The biggest problem with the feature request is not how useful it would
be: I agree it would be useful. The biggest problem is that it is a little
bit of an ill-defined problem.
Imagine that you are rebasing 30 patches. Now, let's assume that patch #7
causes a merge conflict, and you mistakenly call `git rebase --skip`.
Now, when is the next possible time you can call `git rebase --undo-skip`?
It could be after a merge conflict in #8. Or in interactive rebase, after
a `pick` that was turned into an `edit`. Or, and this is also entirely
possible, after the rebase finished with #30 without problems and the
rebase is actually no longer in progress.
So I do not think that there is a way, in general, to implement this
feature. Even if you try to remember the state where a `--skip` was
called, you would remember it in the .git/rebase-apply/ (or
.git/rebase-merge/) directory, which is cleaned up after the rebase
concluded successfully. So even then the information required to implement
the feature would not necessarily be there, still, when it would be needed.