Re: [PATCH 6/6] sha1_name: implement @{push} shorthand
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 31, 2015, 22:57 UTC
- Message-ID
- <xmqqmw2sojv2.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <20150331223200.GC31948@peff.net>
Jeff King <peff@peff.net> writes:
Show 17 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.No, I am not saying we should not detect an error.
Show 6 quoted lines
>> 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?I often interact with this remote called 'ko'. Do I have remote-tracking branch to keep track of its 'master' branch, and if so, what is it?
Isn't that the question that the apply_refspecs() is answering?
> If you remove the die() message, > it is literally a one-liner.
Yes, I thought I said that here...
>> 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.
Show 15 quoted lines
>> 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".Yeah, I thought I said that, too ;-)
Show 6 quoted lines
> 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. :-/
OK.