Re: [PATCH 6/6] sha1_name: implement @{push} shorthand
From: Junio C Hamano <hidden>
Date: 2016-06-15 23:04:20
Jeff King [off-list ref] writes:
quoted hunk
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.
quoted hunk
@@ -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.