Hi Jake, On Wed, 14 Feb 2018, Jacob Keller wrote: > On Wed, Feb 14, 2018 at 5:50 PM, Psidium Guajava <psiidium@xxxxxxxxx> wrote: > > 2018-02-14 22:53 GMT-02:00 Johannes Schindelin <Johannes.Schindelin@xxxxxx>: > >> Now, when is the next possible time you can call `git rebase --undo-skip`? > > > > What if the scope were reduced from `--undo-skip` to `--undo-last-skip`? > > Also, further reduce the scope to only allow `--undo-last-skip` during > > a ongoing rebase, not caring about a finished one? > > > > But, this could be so niche that I have doubts if this would ever be used; > > I think this is too niche to actually be useful in practice, > especially since figuring out exactly what to replay might be tricky.. > I suppose it could keep track of where in the rebase the last skip was > used, and then just go back to rebase and stop there again? That > sounds like just redoing the rebase is easier.. (ie: use the reflog to > go back to before the rebase started, and then re-run it again and > don't skip this time). Yes, and having a record of what commits were skipped would probably be very helpful not only in this instance. Maybe also a record of what commits caused merge conflicts, which a mapping between original and new commit (which does get a bit tricky with fixup!/squash! commits, though). Ciao, Dscho
