Hi Luc, On Mon, 3 Dec 2018, Luc Van Oostenryck wrote: > On Sat, Dec 01, 2018 at 03:02:09PM -0500, Jeff King wrote: > > On Thu, Nov 29, 2018 at 09:32:48AM +0100, Johannes Schindelin wrote: > > > > > > > Would it not make more sense to add a command-line option (and a config > > > > > setting) to re-schedule failed `exec` commands? Like so: > > > > > > > > Your proposition would do in most cases, however it is not possible to > > > > make a distinction between reschedulable and non-reschedulable commands. > > > > > > True. But I don't think that's so terrible. > > > > > > What I think is something to avoid is two commands that do something very, > > > very similar, but with two very, very different names. > > > > > > In reality, I think that it would even make sense to change the default to > > > reschedule failed `exec` commands. Which is why I suggested to also add a > > > config option. > > > > 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. 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 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 (assuming that the latest 3 commits were non-merge commits; It would look quite a bit more complicated in other situations.) Ciao, Dscho
