Re: [PATCH v5 4/9] fetch: print left-hand side when fetching HEAD:foo

From: Jeff King <peff@peff.net>
Date: May 13, 2023, 16:59 UTC
Message-ID: <20230513165925.GA113985@coredump.intra.peff.net>
In-Reply-To: <2cc7318697ef6062f6deadf7a22feb26c2c829e8.1683721293.git.ps@pks.im>

On Wed, May 10, 2023 at 02:34:15PM +0200, Patrick Steinhardt wrote:

Show 8 quoted lines

> @@ -946,7 +948,7 @@ static int update_local_ref(struct ref *ref,
>  	if (oideq(&ref->old_oid, &ref->new_oid)) {
>  		if (verbosity > 0)
>  			display_ref_update(display_state, '=', _("[up to date]"), NULL,
> -					   remote, ref->name, summary_width);
> +					   remote_ref->name, ref->name, summary_width);
>  		return 0;
>  	}

Here (and in other hunks) we now dereference remote_ref unconditionally. But in existing parts of the code, we guard against remote_ref being NULL. E.g., later on:

          if (!current || !updated) {
                  const char *msg;
                  const char *what;
                  int r;
                  /*
                   * Nicely describe the new ref we're fetching.
                   * Base this on the remote's ref name, as it's
                   * more likely to follow a standard layout.
                   */
                  const char *name = remote_ref ? remote_ref->name : "";
		  [...]

I'm not sure if the old code was being overly defensive, or if the new code is ripe for a segfault. But it's probably worth looking into (it was noticed by Coverity).

Looking at the caller, it is always store_update_refs() which passes its own "rm", a pointer iterating over ref_map. And it should always be non-NULL, since that's the loop condition.

So I think your code is fine, but you might want to double-check my logic. (And it may be worth cleaning up the existing redundant check to prevent confusion).

-Peff