Hi Peff, On Sat, 1 Dec 2018, 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. Yep, `break`, as Eric pointed out. After all, you did not really want a command to fail, you just wanted the interactive rebase to give you a break. > 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. > > How would I move past the test that fails to continue? I guess "git > rebase --edit-todo" and then manually remove it (and any other remaining > test lines)? Yes, the current way would be to use `git rebase --edit-todo`. > That's not too bad, but I wonder if people would find it more awkward > than the current way (which is to just "rebase --continue" until you get > to the end). > > I dunno. I am not sure if I am for or against changing the default, so > these are just some musings. :) It's good that you chimed in with your side of things. If you missed the `break` command, so will many others have missed it. And continue to miss it. Besides, Junio mentioned elsewhere that he is in the camp of people who wait for enough users to complain why some config option isn't the default to actually change the default. So... I guess we'll leave the default where it is for now. Ciao, Dscho
