From: Jeff King <peff@peff.net>
Date: Mon, 27 Aug 2012 09:25:02 GMT
Subject: Re: [PATCH 04/17] Name local variables more consistently
Message-ID: <20120827092502.GA2428@sigill.intra.peff.net>
In-Reply-To: <503B3C5C.1020109@alum.mit.edu>

On Mon, Aug 27, 2012 at 11:22:36AM +0200, Michael Haggerty wrote:

> > Using one name is better, but I wonder "heads" is the better one
> > between the two.
> > 
> > After all, this codepath is not limited to branches these days as
> > the word "head" implies.  Rather, <nr_thing, thing> has what we
> > asked for, and <refs> has what the other sides have, and we are
> > trying to make sure we haven't asked what they do not have in this
> > function.
> > 
> > And the way we do so is to match the "thing"s with what are in
> > "refs" to find unmatched ones.
> > 
> > So between the two, I would have chosen "match" instead of "heads"
> > to call the "thing".
> 
> When I decided between "heads" and "match", my main consideration was
> that "match" sounds like something that has already been matched, not
> something that is being matched against.  The word "match" also implies
> to me that some nontrivial matching process is going on, like glob
> expansion.
> 
> But I agree with you that "heads" also has disadvantages.
> 
> What about a third option: "refnames"?  This name makes it clear that we
> are talking about simple names as opposed to "struct ref" or some kind
> of refname glob patterns and also makes it clear that they are not
> necessarily all branches.  It would also be distinct from the "refs"
> linked list that is often used in the same functions.

Yeah, I agree that "refnames" would be better. I think something like
"spec" or "refspec" would indicate better that they are to be matched
against, but then you run afoul of confusing that with colon-delimited
refspecs (which I do not think fetch-pack understands at all).

-Peff