Re: [PATCH v2] sub-process: print the cmd when a capability is unsupported
> On 11 Sep 2017, at 05:27, Junio C Hamano wrote: > > Junio C Hamano writes: > >> I still think we would want to turn warning() to die(), but it >> probably is better to do so in a separate follow-up patch. That >> will give us a good place to record the reason why the current "just >> call a warning() and pretend as if nothing bad happend" is wrong. > > And here is such an update. It seems that pretty much all comments > in the original thread were "warning is wrong--we should die here", > but nobody seems to have bothered following it through. > > cf. <20170815111725.5d009...@twelve2.svl.corp.google.com> > > -- >8 -- > Subject: [PATCH] subprocess: loudly die when subprocess asks for an > unsupported capability > > The handshake_capabilities() function first advertises the set of > capabilities it supports, so that the other side can pick and choose > which ones to use and ask us to enable in its response. Then we > read the response that tells us what choice the other side made. If > we saw something that we never advertised, that indicates one of two > things. The other side, i.e. the "upgraded" filter, is not paying > attention of the capabilities advertisement, and asking something > its correct operation relies on, but we are not capable of giving > that unknown feature and operate without it, so after that point the > exchange of data is a garbage-in-garbage-out. Or the other side > wanted to ask for one of the capabilities we advertised, but the > code has typo and their wish to enable a capability that its correct > operation relies on is not understood on this end. The result is > the same garbage-in-garbage-out. > > Instead of sweeping such a potential bug under the rug, die loudly > when we see a request for an unsupported capability in order to > force sloppily-written filter scripts to get corrected. > > Signed-off-by: Junio C Hamano > --- > sub-process.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sub-process.c b/sub-process.c > index fcc4832c14..ec9a51b7b1 100644 > --- a/sub-process.c > +++ b/sub-process.c > @@ -181,8 +181,8 @@ static int handshake_capabilities(struct child_process > *process, > if (supported_capabilities) > *supported_capabilities |= capabilities[i].flag; > } else { > - warning("subprocess '%s' requested unsupported > capability '%s'", > - process->argv[0], p); > + die("subprocess '%s' requested unsupported capability > '%s'", > + process->argv[0], p); Looks good! Thank you, Lars
Re: [PATCH v2] sub-process: print the cmd when a capability is unsupported
On 9/10/2017 11:27 PM, Junio C Hamano wrote: Junio C Hamano writes: I still think we would want to turn warning() to die(), but it probably is better to do so in a separate follow-up patch. That will give us a good place to record the reason why the current "just call a warning() and pretend as if nothing bad happend" is wrong. And here is such an update. It seems that pretty much all comments in the original thread were "warning is wrong--we should die here", but nobody seems to have bothered following it through. cf. <20170815111725.5d009...@twelve2.svl.corp.google.com> -- >8 -- Subject: [PATCH] subprocess: loudly die when subprocess asks for an unsupported capability The handshake_capabilities() function first advertises the set of capabilities it supports, so that the other side can pick and choose which ones to use and ask us to enable in its response. Then we read the response that tells us what choice the other side made. If we saw something that we never advertised, that indicates one of two things. The other side, i.e. the "upgraded" filter, is not paying attention of the capabilities advertisement, and asking something its correct operation relies on, but we are not capable of giving that unknown feature and operate without it, so after that point the exchange of data is a garbage-in-garbage-out. Or the other side wanted to ask for one of the capabilities we advertised, but the code has typo and their wish to enable a capability that its correct operation relies on is not understood on this end. The result is the same garbage-in-garbage-out. Instead of sweeping such a potential bug under the rug, die loudly when we see a request for an unsupported capability in order to force sloppily-written filter scripts to get corrected. The documentation states "Git expects to read a list of desired capabilities, ***which must be a subset of the supported capabilities list*** and a flush packet as response:" Anything else is clearly a bug so a "die" is more appropriate than a warning. Patch looks good. Thanks for making sure this didn't fall through the cracks. Signed-off-by: Junio C Hamano --- sub-process.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sub-process.c b/sub-process.c index fcc4832c14..ec9a51b7b1 100644 --- a/sub-process.c +++ b/sub-process.c @@ -181,8 +181,8 @@ static int handshake_capabilities(struct child_process *process, if (supported_capabilities) *supported_capabilities |= capabilities[i].flag; } else { - warning("subprocess '%s' requested unsupported capability '%s'", - process->argv[0], p); + die("subprocess '%s' requested unsupported capability '%s'", + process->argv[0], p); } }
Re: [PATCH v2] sub-process: print the cmd when a capability is unsupported
Junio C Hamano writes: > I still think we would want to turn warning() to die(), but it > probably is better to do so in a separate follow-up patch. That > will give us a good place to record the reason why the current "just > call a warning() and pretend as if nothing bad happend" is wrong. And here is such an update. It seems that pretty much all comments in the original thread were "warning is wrong--we should die here", but nobody seems to have bothered following it through. cf. <20170815111725.5d009...@twelve2.svl.corp.google.com> -- >8 -- Subject: [PATCH] subprocess: loudly die when subprocess asks for an unsupported capability The handshake_capabilities() function first advertises the set of capabilities it supports, so that the other side can pick and choose which ones to use and ask us to enable in its response. Then we read the response that tells us what choice the other side made. If we saw something that we never advertised, that indicates one of two things. The other side, i.e. the "upgraded" filter, is not paying attention of the capabilities advertisement, and asking something its correct operation relies on, but we are not capable of giving that unknown feature and operate without it, so after that point the exchange of data is a garbage-in-garbage-out. Or the other side wanted to ask for one of the capabilities we advertised, but the code has typo and their wish to enable a capability that its correct operation relies on is not understood on this end. The result is the same garbage-in-garbage-out. Instead of sweeping such a potential bug under the rug, die loudly when we see a request for an unsupported capability in order to force sloppily-written filter scripts to get corrected. Signed-off-by: Junio C Hamano --- sub-process.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sub-process.c b/sub-process.c index fcc4832c14..ec9a51b7b1 100644 --- a/sub-process.c +++ b/sub-process.c @@ -181,8 +181,8 @@ static int handshake_capabilities(struct child_process *process, if (supported_capabilities) *supported_capabilities |= capabilities[i].flag; } else { - warning("subprocess '%s' requested unsupported capability '%s'", - process->argv[0], p); + die("subprocess '%s' requested unsupported capability '%s'", + process->argv[0], p); } } -- 2.14.1-660-g2f12cdf511
Re: [PATCH v2] sub-process: print the cmd when a capability is unsupported
Junio C Hamano writes: > Ben Peart writes: > >>> - warning("external filter requested unsupported filter >>> capability '%s'", >>> - p); >>> + warning("subprocess '%s' requested unsupported >>> capability '%s'", >>> + process->argv[0], p); >>> } >>> } >>> >>> >> >> This one is even cleaner. Thanks Lars for pointing out the fact we >> already had the cmd name. Looks good. > > Thanks, all. Will queue. I still think we would want to turn warning() to die(), but it probably is better to do so in a separate follow-up patch. That will give us a good place to record the reason why the current "just call a warning() and pretend as if nothing bad happend" is wrong.
Re: [PATCH v2] sub-process: print the cmd when a capability is unsupported
Ben Peart writes: >> -warning("external filter requested unsupported filter >> capability '%s'", >> -p); >> +warning("subprocess '%s' requested unsupported >> capability '%s'", >> +process->argv[0], p); >> } >> } >> >> > > This one is even cleaner. Thanks Lars for pointing out the fact we > already had the cmd name. Looks good. Thanks, all. Will queue.
Re: [PATCH v2] sub-process: print the cmd when a capability is unsupported
> On 16 Aug 2017, at 14:40, Christian Couder wrote: > > In handshake_capabilities() we use warning() when a capability > is not supported, so the exit code of the function is 0 and no > further error is shown. This is a problem because the warning > message doesn't tell us which subprocess cmd failed. > > On the contrary if we cannot write a packet from this function, > we use error() and then subprocess_start() outputs: > >initialization for subprocess '' failed > > so we can know which subprocess cmd failed. > > Let's improve the warning() message, so that we can know which > subprocess cmd failed. > > Helped-by: Lars Schneider > Signed-off-by: Christian Couder > --- > Change since previous version: > > - Use process->argv[0] instead of adding a new parameter to >handshake_capabilities(), thanks to Lars. > > sub-process.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/sub-process.c b/sub-process.c > index 6edb97c1c6..6ccfaaba99 100644 > --- a/sub-process.c > +++ b/sub-process.c > @@ -184,8 +184,8 @@ static int handshake_capabilities(struct child_process > *process, > if (supported_capabilities) > *supported_capabilities |= capabilities[i].flag; > } else { > - warning("external filter requested unsupported filter > capability '%s'", > - p); > + warning("subprocess '%s' requested unsupported > capability '%s'", > + process->argv[0], p); > } > } > > -- > 2.14.1.146.g7de11f915a > Looks good to me. Thanks, Lars
Re: [PATCH v2] sub-process: print the cmd when a capability is unsupported
On 8/16/2017 8:40 AM, Christian Couder wrote: In handshake_capabilities() we use warning() when a capability is not supported, so the exit code of the function is 0 and no further error is shown. This is a problem because the warning message doesn't tell us which subprocess cmd failed. On the contrary if we cannot write a packet from this function, we use error() and then subprocess_start() outputs: initialization for subprocess '' failed so we can know which subprocess cmd failed. Let's improve the warning() message, so that we can know which subprocess cmd failed. Helped-by: Lars Schneider Signed-off-by: Christian Couder --- Change since previous version: - Use process->argv[0] instead of adding a new parameter to handshake_capabilities(), thanks to Lars. sub-process.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sub-process.c b/sub-process.c index 6edb97c1c6..6ccfaaba99 100644 --- a/sub-process.c +++ b/sub-process.c @@ -184,8 +184,8 @@ static int handshake_capabilities(struct child_process *process, if (supported_capabilities) *supported_capabilities |= capabilities[i].flag; } else { - warning("external filter requested unsupported filter capability '%s'", - p); + warning("subprocess '%s' requested unsupported capability '%s'", + process->argv[0], p); } } This one is even cleaner. Thanks Lars for pointing out the fact we already had the cmd name. Looks good.