Re: [PATCH 6/6] sha1_name: implement @{push} shorthand
- From
Jeff King <peff@peff.net>
- Date
- Mar 31, 2015, 22:32 UTC
- Message-ID
- <20150331223200.GC31948@peff.net>
- In-Reply-To
- <xmqqk2xwq25m.fsf@gitster.dls.corp.google.com>
On Tue, Mar 31, 2015 at 02:37:25PM -0700, Junio C Hamano wrote:
Show 19 quoted lines
> Jeff King <peff@peff.net> 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.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).
Show 13 quoted lines
> > +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().
Show 16 quoted lines
> 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