Re: [PATCH] rebase -i: introduce the 'test' command
- From
- Phillip Wood <phillip.wood@talktalk.net>
- Date
- Dec 3, 2018, 14:31 UTC
- Message-ID
- <ab4b0a47-858e-659f-f970-944b7c5313fc@talktalk.net>
- In-Reply-To
- <20181201200209.GC29120@sigill.intra.peff.net>
On 01/12/2018 20:02, Jeff King wrote:
Show 34 quoted lines
> 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. > > 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)?
Perhaps we could teach git rebase --skip to skip a rescheduled command, it could be useful if people want to skip rescheduled picks as well (though I don't think I've ever had that happen in the wild). I can see myself turning on the rescheduling config setting but occasionally wanting to be able to skip over the rescheduled exec command.
Best Wishes
Phillip
Show 9 quoted lines
> 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. :) > > -Peff >