On Mon, Dec 03, 2018 at 08:01:44PM +0100, Johannes Schindelin wrote: > Hi Luc, > > On Mon, 3 Dec 2018, Luc Van Oostenryck wrote: > > > On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote: > > > I sometimes add "x false" to the top of the todo list to stop and create > > > new commits before the first one. That would be awkward if I could never > > > get past that line. However, I think elsewhere a "pause" line has been > > > discussed, which would serve the same purpose. > > > > > > I wonder how often this kind of "yes, I know it fails, but keep going > > > anyway" situation would come up. And what the interface is like for > > > getting past it. E.g., what if you fixed a bunch of stuff but your tests > > > still fail? You may not want to abandon the changes you've made, but you > > > need to "rebase --continue" to move forward. I encounter this often when > > > the correct fix is actually in an earlier commit than the one that > > > yields the test failure. You can't rewind an interactive rebase, so I > > > complete and restart it, adding an "e"dit at the earlier commit. > > > > In this sort of situation, I often whish to be able to do nested rebases. > > Even more because it happen relatively often that I forget that I'm > > working in a rebase and not on the head, and then it's quite natural > > to me to type things like 'git rebase -i @^^^' while already rebasing. > > But I suppose this has already been discussed. > > Varieties of this have been discussed, but no, not nested rebases. Interesting :) > The closest we thought about was re-scheduling the latest <n> commits, > which is now harder because of the `--rebase-merges` mode. > > But I think it would be doable. Your idea of a "nested" rebase actually > opens that door quite nicely. It would not *really* be a nested rebase, > and it would still only be possible in interactive mode, but I could > totally see > > git rebase --nested -i HEAD~3 I don't mind much if it would be "really nested" or "as-if nested" but with this flag --nested I wonder what would happen if I would use it in a 'top-level' rebase (or, said in another way, would I be able to alias 'rebase' to 'rebase --nested')? > to generate and prepend the following lines to the `git-rebase-todo` file: > > reset abcdef01 # This is HEAD~3 > pick abcdef02 # This is HEAD~2 > pick abcdef03 # This is HEAD~ > pick abcdef04 # This is HEAD > OK, I see. This would not be nestable/stackable but would solve the problem nicely. Best regards, -- Luc
