From: Reece Dunn <msclrhd@googlemail.com>
To: Jeff King <peff@peff.net>
Cc: Giuseppe Scrivano <gscrivano@gnu.org>,
git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Sverre Rabbelier <srabbelier@gmail.com>
Subject: Re: [PATCH] Remove various dead assignments and dead increments found by the clang static analyzer
Date: Sat, 26 Sep 2009 22:20:18 +0100 [thread overview]
Message-ID: <3f4fd2640909261420h2588df4cld8dd3e49f9654e9e@mail.gmail.com> (raw)
In-Reply-To: <20090926211220.GA3387@coredump.intra.peff.net>
2009/9/26 Jeff King <peff@peff.net>:
> On Sat, Sep 26, 2009 at 10:03:27PM +0100, Reece Dunn wrote:
>
>> > Now this is one that I do think is sensible. The variable isn't used, so
>> > don't even bother declaring it.
>>
>> The status variable is removed in this patch.
>
> Yes. Sorry if I wasn't clear, but what I meant was "this does not fall
> under the same idioms as the other ones, and it is a fine thing to be
> removing".
Sure.
>> But then shouldn't the status returned be checked and acted on? That
>> is, are failures from run_command_v_opt being reported to the user, or
>> otherwise reacted to?
>
> Perhaps. This is the post-update hook, so at that point we have already
> committed any changes to the repository. Usually it is used for running
> "git update-server-info" for repositories available over dumb protocols.
>
> So there is no useful action for receive-pack to do after seeing an
> error. But I said "perhaps" above, because it might be useful to notify
> the user over the stderr sideband that the hook failed. Even though we
> have no action to take, the user might care or want to investigate a
> potential problem.
>
> I suspect nobody has cared about this before, though, because the stderr
> channel for the hook is also directed to the user. So if
> update-server-info (or whatever) fails, presumably it is complaining to
> stderr and the user sees that. Adding an additional "by the way, your
> hook failed" is just going to be noise in most cases.
It could be used to return an error status from main if it is used in
a chained command in a script. Other than that, I agree.
>> Thus having the same effect (removing the status variable). Callers of
>> run_update_post_hook should be checked as well, as should other
>> run_command_* calls.
>
> There is exactly one caller, and it doesn't care about the return code
> for the reasons mentioned above.
Including being called from a script?
- Reece
next prev parent reply other threads:[~2009-09-26 21:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-26 14:46 [PATCH] Remove various dead assignments and dead increments found by the clang static analyzer Giuseppe Scrivano
2009-09-26 15:58 ` Johannes Schindelin
2009-09-26 18:21 ` Giuseppe Scrivano
2009-09-26 18:34 ` Sverre Rabbelier
2009-09-26 18:46 ` Giuseppe Scrivano
2009-09-26 19:15 ` Giuseppe Scrivano
2009-09-26 19:28 ` René Scharfe
2009-09-26 20:39 ` Johannes Schindelin
2009-09-26 20:46 ` Jeff King
2009-09-26 21:03 ` Reece Dunn
2009-09-26 21:12 ` Jeff King
2009-09-26 21:20 ` Reece Dunn [this message]
2009-09-26 21:36 ` Jeff King
2009-09-26 21:46 ` Reece Dunn
2009-09-26 21:42 ` Giuseppe Scrivano
2009-09-27 0:41 ` Nicolas Pitre
2009-09-27 8:21 ` Giuseppe Scrivano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3f4fd2640909261420h2588df4cld8dd3e49f9654e9e@mail.gmail.com \
--to=msclrhd@googlemail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gscrivano@gnu.org \
--cc=peff@peff.net \
--cc=srabbelier@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).