git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
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 20:46:43 -0400	[thread overview]
Message-ID: <20150522004643.GA11739@peff.net> (raw)
In-Reply-To: <xmqqpp5tivga.fsf@gitster.dls.corp.google.com>

On Thu, May 21, 2015 at 12:25:57PM -0700, Junio C Hamano wrote:

> > Note also that the original may dereference branch->merge[0] even if it
> > is NULL. I think that can't actually happen in practice (we only
> > allocate branch->merge if we have at least one item to put in it, and
> > all of the checks of branch->merge[0] are actually being over-careful).
> > But the code I just wrote above does not have that problem.
> 
> Perhaps update the patch with this explanation in the log message,
> as a separate preparatory step?

I decided on a separate patch on top which improves the logic and
explains the issues. Here it is (it goes on top of the existing patch 8,
"report specific errors from branch_get_upstream").

-- >8 --
Subject: remote.c: untangle error logic in branch_get_upstream

The error-diagnosis logic in branch_get_upstream was copied
straight from sha1_name.c in the previous commit. However,
because we check all error cases and upfront and then later
diagnose them, the logic is a bit tangled. In particular:

  - if branch->merge[0] is NULL, we may end up dereferencing
    it for an error message (in practice, it should never be
    NULL, so this is probably not a triggerable bug).

  - We may enter the code path because branch->merge[0]->dst
    is NULL, but we then start our error diagnosis by
    checking whether our local branch exists. But that is
    only relevant to diagnosing missing merge config, not a
    missing tracking ref; our diagnosis may hide the real
    problem.

Instead, let's just use a sequence of "if" blocks to check
for each error type, diagnose it, and return NULL.

Signed-off-by: Jeff King <peff@peff.net>
---
 remote.c | 19 +++++++++++++------
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/remote.c b/remote.c
index 1b7051a..d2519c2 100644
--- a/remote.c
+++ b/remote.c
@@ -1721,18 +1721,25 @@ 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 (!branch->merge || !branch->merge[0]) {
+		/*
+		 * no merge config; is it because the user didn't define any,
+		 * or because it is not a real branch, and get_branch
+		 * auto-vivified it?
+		 */
 		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,
+				 _("no upstream configured for branch '%s'"),
+				 branch->name);
+	}
+
+	if (!branch->merge[0]->dst)
 		return error_buf(err,
 				 _("upstream branch '%s' not stored as a remote-tracking branch"),
 				 branch->merge[0]->src);
-	}
 
 	return branch->merge[0]->dst;
 }
-- 
2.4.1.528.g00591e3

  reply	other threads:[~2015-05-22  0:46 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
2015-05-21 18:49     ` Jeff King
2015-05-21 19:25       ` Junio C Hamano
2015-05-22  0:46         ` Jeff King [this message]
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=20150522004643.GA11739@peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sunshine@sunshineco.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).