Jeff King <peff@xxxxxxxx> writes:
> 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.
> @@ -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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html