Hi Elijah, On Mon, 10 Dec 2018, Elijah Newren wrote: > On Mon, Dec 10, 2018 at 3:13 PM Johannes Schindelin via GitGitGadget > <gitgitgadget@xxxxxxxxx> wrote: > > > > The idea was brought up by Paul Morelle. > > > > To be honest, this idea of rescheduling a failed exec makes so much sense > > that I wish we had done this from the get-go. > > > > So let's do the next best thing: implement a command-line option and a > > config setting to make it so. > > > > The obvious intent behind that config setting is to not only give users a > > way to opt into that behavior already, but also to make it possible to flip > > the default at a later date, after the feature has been battle-tested and > > after deprecating the non-rescheduling behavior for a couple of Git > > versions. > > > > If the team agrees with my reasoning, then the 3rd patch (introducing -y > > <cmd> as a shortcut for --reschedule-failed-exec -x <cmd>) might not make > > much sense, as it would introduce a short option that would become obsolete > > soon. > > > > Complete side-track: This email showed up for me just five minutes > ago, whereas the rest of the series showed up four hours ago, making > me think this email had disappeared and trying to figure out how to > respond when I didn't have the original. Any ideas why there might be > that level of lag? I have such email woes for roughly half a year now. No idea where this comes from, whether this is some graylisting at work, or whether the `<author> via GitGitGadget` marks gitgitgadget@xxxxxxxxx as suspect with some mail providers and/or central lists of dubious email addresses. At first, I thought it was only GMX, but yes, I also see it with GMail now. Ciao, Dscho