From: Junio C Hamano <gitster@pobox•com>
To: Jeff King <peff@peff•net>
Cc: git@vger•kernel.org, Eric Sunshine <sunshine@sunshineco•com>
Subject: Re: [PATCH v3 08/14] remote.c: report specific errors from branch_get_upstream
Date: Thu, 21 May 2015 11:33:58 -0700 [thread overview]
Message-ID: <xmqq7fs1kcfd.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150521044532.GH23409@peff.net> (Jeff King's message of "Thu, 21 May 2015 00:45:32 -0400")
Jeff King <peff@peff•net> writes:
> diff --git a/remote.c b/remote.c
> index dca3442..1b7051a 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1705,10 +1705,35 @@ int branch_merge_matches(struct branch *branch,
> return refname_match(branch->merge[i]->src, refname);
> }
>
> -const char *branch_get_upstream(struct branch *branch)
> +__attribute((format (printf,2,3)))
> +static const char *error_buf(struct strbuf *err, const char *fmt, ...)
> {
> - if (!branch || !branch->merge || !branch->merge[0])
> - return NULL;
> + if (err) {
> + va_list ap;
> + va_start(ap, fmt);
> + strbuf_vaddf(err, fmt, ap);
> + va_end(ap);
> + }
> + return NULL;
> +}
Many of our functions return -1 to signal an error, and that is why
it makes sense for our error() helper to return -1 to save code in
the caller, but only because the callers of this private helper use
a NULL to signal an error, this also returns NULL. If we were to
use the "callers can opt into detailed message by passing strbuf"
pattern more widely, we would want a variant of the above that
returns -1, too. And such a helper would do the same thing as
above, with only difference from the above is to return -1.
It's a shame that we have to return something from this function,
whose primary purpose is "we may or may not want an error message in
a strbuf, so format the message when and only when we give you a
strbuf", but C forces us to make it "always return NULL to signal an
error to the caller, and optionally format the message into a strbuf
if given".
And the name of this helper function only captures the "optionally
format the message" part, not the "always return NULL" part.
> +const char *branch_get_upstream(struct branch *branch, struct strbuf *err)
> +{
> + if (!branch)
> + return error_buf(err, _("HEAD does not point to a branch"));
> + if (!branch->merge || !branch->merge[0] || !branch->merge[0]->dst) {
> + if (!ref_exists(branch->refname))
> + return error_buf(err, _("no such branch: '%s'"),
> + branch->name);
> + if (!branch->merge)
> + return error_buf(err,
> + _("no upstream configured for branch '%s'"),
> + branch->name);
> + return error_buf(err,
> + _("upstream branch '%s' not stored as a remote-tracking branch"),
> + branch->merge[0]->src);
> + }
> +
> return branch->merge[0]->dst;
> }
This is a faithful conversion of what the get_upstream_branch() used
to do, but that ref_exists() check and the error checking there look
somewhat out of place.
It makes the reader wonder what should happen when "branch->refname"
does not exist as a ref, but "branch->merge[0]->dst" can be fully
dereferenced. Should it be an error, or if it is OK, the reason why
it is OK is...?
next prev parent reply other threads:[~2015-05-21 18:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-21 4:44 [PATCH v3 0/14] implement @{push} shorthand Jeff King
2015-05-21 4:45 ` [PATCH v3 01/14] remote.c: drop default_remote_name variable Jeff King
2015-05-21 4:45 ` [PATCH v3 02/14] remote.c: refactor setup of branch->merge list Jeff King
2015-05-21 17:47 ` Junio C Hamano
2015-05-21 4:45 ` [PATCH v3 03/14] remote.c: drop "remote" pointer from "struct branch" Jeff King
2015-05-21 4:45 ` [PATCH v3 04/14] remote.c: hoist branch.*.remote lookup out of remote_get_1 Jeff King
2015-05-21 4:45 ` [PATCH v3 05/14] remote.c: provide per-branch pushremote name Jeff King
2015-05-21 4:45 ` [PATCH v3 06/14] remote.c: hoist read_config into remote_get_1 Jeff King
2015-05-21 4:45 ` [PATCH v3 07/14] remote.c: introduce branch_get_upstream helper Jeff King
2015-05-21 18:07 ` Junio C Hamano
2015-05-21 18:14 ` Jeff King
2015-05-21 18:35 ` Jeff King
2015-05-21 19:16 ` Junio C Hamano
2015-05-21 4:45 ` [PATCH v3 08/14] remote.c: report specific errors from branch_get_upstream Jeff King
2015-05-21 18:33 ` Junio C Hamano [this message]
2015-05-21 18:49 ` Jeff King
2015-05-21 19:25 ` Junio C Hamano
2015-05-22 0:46 ` Jeff King
2015-05-22 0:49 ` Jeff King
2015-05-21 4:45 ` [PATCH v3 09/14] remote.c: add branch_get_push Jeff King
2015-05-21 4:45 ` [PATCH v3 10/14] sha1_name: refactor upstream_mark Jeff King
2015-05-21 4:45 ` [PATCH v3 11/14] sha1_name: refactor interpret_upstream_mark Jeff King
2015-05-21 4:45 ` [PATCH v3 12/14] sha1_name: implement @{push} shorthand Jeff King
2015-05-21 4:45 ` [PATCH v3 13/14] for-each-ref: use skip_prefix instead of starts_with Jeff King
2015-05-21 4:45 ` [PATCH v3 14/14] for-each-ref: accept "%(push)" format Jeff King
2015-05-21 4:52 ` [PATCH v3 0/14] implement @{push} shorthand Jeff King
2015-05-21 18:37 ` Junio C Hamano
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=xmqq7fs1kcfd.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
--cc=sunshine@sunshineco$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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