Re: git-rebase --undo-skip proposal
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Feb 15, 2018, 13:06 UTC
- Message-ID
- <nycvar.QRO.7.76.6.1802151403360.35@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
- In-Reply-To
- <CA+P7+xpBW7Sq89f5RK6cCcLYGR0Rh0aWdWrhqjerKUi5xUUKtQ@mail.gmail.com>
Hi Jake,
On Wed, 14 Feb 2018, Jacob Keller wrote:
Show 17 quoted lines
> On Wed, Feb 14, 2018 at 5:50 PM, Psidium Guajava <psiidium@gmail.com> wrote: > > 2018-02-14 22:53 GMT-02:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>: > >> 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