On Tue, Feb 20, 2018 at 12:44:51PM +0100, Johannes Schindelin wrote: > > It might be even possible to design a new subcommand for the interactive > > rebase to facilitate a variation of this strategy (possibly even making > > use of the fact that the interactive rebase accumulates mappings between > > the original commits and the rewritten ones in > > $GIT_DIR/rebase-merge/rewritten-list, intended for use in the post-rewrite > > hook). > > This feature might look somewhat like this: > > git rebase --replay-latest-commits 3 > > and it would not even have to look at the `rewritten-list`. All it would > do is to put back the latest `pick` from the `done` file (in case of merge > conflicts) into the `git-rebase-todo` file, then insert `pick lines for > HEAD~3.. at the beginning of that todo file, and then `git reset --hard > HEAD~3`. Keep in mind that the "pick" lines could be "edit", "squash", etc. I think the general form of your original email's proposal is something like: What if we had a "git rebase --rewind" that could "undo" the prior command? So if I had a todo file like: pick 1 edit 2 x make test edit 3 x make test pick 4 and I failed at the second "make test", then I'd have: pick 1 edit 2 x make test edit 3 x make test in the "done" file, with the final pick remaining in "todo". Could I then ask to "rewind" my state by moving "x make test" back to the "todo". And two rewinds would get me back to applying patch 3, which I could then fix up and re-run my test. Or four rewinds would get me back to patch 2, which maybe is where I made the initial mistake. That's a bit more primitive than what you're proposing in this follow-on, because you'd be doing the replay yourself (unless we remap the commits). But it's very easy to reason about and implement. Anyway, just musing at this point. I haven't thought it through, but I like the direction of everything you're saying. ;) -Peff
