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