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

Jeff King [off-list ref] writes:

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.

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.

On Tue, Mar 31, 2015 at 02:37:25PM -0700, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

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.

They are necessary inside single-quotes, but not inside backticks. IMHO
this entire file should be using backticks, but I didn't want to
reformat the entire file (and so I tried to at least keep the heading in
the same style as the rest of it).

quoted

+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.

I am not sure I understand. We do _not_ have a local name we use to
track it. That is the error. I can print "remote %s does not have branch
%s", if that is what you mean.

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?

Is it really a useful general function? If you remove the die() message,
it is literally a one-liner. My purpose in pulling it out at all was not
to repeat the die() message over and over in get_push_branch().

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.

I think it is more complicated, as there are actually two arrays indexed
by each {fetch,push}_refspec_nr. We have "fetch_respec", which contains
the text (I assume), and then the "struct refspec". So ideally those
would be stored together in a single list, but of course many helper
functions want just the "struct refspec" list. So you still end up with
two lists, but just pushed down into a single struct. I guess that's
better, but I was trying to find a bound to my refactoring rather than
touching all of the code. :-/

-Peff