On Tue, Feb 20, 2018 at 12:56 PM, Jeff King <p...@peff.net> wrote: > 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
Using a --rewind that simply tracks the point of each history and can reset back to each seems a bit more inline with what the original suggestion is. Sort of like "undo" in an editor might. You could even add a "rewind=x" so it could go back more than one step at a time, tho just re-running rewind until you get where you want would be doable as well. I like the overall direction of both these suggestions. Thanks, Jake
