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
> 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).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html