Re: [PATCH 6/6] sha1_name: implement @{push} shorthand

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 31, 2015, 21:37 UTC
Message-ID: <xmqqk2xwq25m.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150331173834.GF18912@peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
> index 0796118..5d9df25 100644
> --- a/Documentation/revisions.txt
> +++ b/Documentation/revisions.txt
> @@ -98,6 +98,31 @@ some output processing may assume ref names in UTF-8.
>    `branch.<name>.merge`).  A missing branchname defaults to the
>    current one.
>  
> +'<branchname>@\{push\}', e.g. 'master@\{push\}', '@\{push\}'::
> +  The suffix `@{push}` reports the branch "where we would push to" if

The corresponding description for upstream begins like this:

  The suffix '@\{upstream\}' to a branchname (short form '<branchname>@\{u\}')

and makes me wonder if the existing backslashes are unnecessary, or if you forgot to use them in the new text.

Show 12 quoted lines

> @@ -1104,6 +1111,95 @@ static int interpret_upstream_mark(const char *name, int namelen,
>  	return len + at;
>  }
>  
> +static char *tracking_ref_for(struct remote *remote, const char *refname)
> +{
> +	char *ret;
> +
> +	ret = apply_refspecs(remote->fetch, remote->fetch_refspec_nr, refname);
> +	if (!ret)
> +		die(_("@{push} has no local tracking branch for remote '%s'"),
> +		    refname);

I would imagine that it would be very plausible that anybody with a specific remote and the name of the ref that appears on that remote would want to learn the local name of the remote-tracking ref we use to track it.

But the error message limits the callers only to those who are involved in @{push} codepath. Shouldn't the error check be done in the caller instead, anticipating the day this useful function ceases to be static?

I would suspect that such a change would make it just a one-liner, but I think this helper that takes remote and their refname is much easier to read than four inlined calls to apply_refspecs() that have to spell out remote->fetch, remote->fetch_refspec_nr separately.

Perhaps we would want

	struct refspecs {
        	int nr, alloc;
                const char **refspec;
	} fetch_refspec;

in "struct remote", instead of these two separate fields, and then make apply_refspecs() take "struct refspecs *"? I haven't checked and thought enough to decide if we want "struct refspec *" also in that new struct, though.