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.
