Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > On 08/26/2012 07:39 PM, Junio C Hamano wrote: > ... >> 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. "refnames" has a similar issue as "match", as you have pointed out, and more. Was it the remote or us who populated the "refnames" (answer: these are "our" refnames, and the other one "refs" is what they have)? What do we have that "refnames" for (answer: these specify what we are going to pick among what they have)? Perhaps "asked"? At the beginning of the processing, we have all that were asked for, and at the end, we leave what were asked for but were not fulfilled. -- 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