"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > The client knows the *name* of the ref, but not the SHA-1 the ref is > currently valued at. Thus when the client knows it wants a certain > ref by name, it needs to send a "want " line to the server that would > give it whatever that ref currently points at. Unfortunately since we > have not obtained that value yet, we are stuck. That could be something you can fix in the out-of-band procedure Gerrit uses (you let the client learn both name and value offline, and then the client uses that value on "want" line). However, even if we limit the discussion to Gerrit, you would need an updated client that can be called with the out-of-band information (i.e. "we know that changes/88/4488/2 points at X, so use X when requesting") when talking with such an updated server. So I think that expand-refs is a much nicer general solution than just "server side is configured to hide but still allow certain refs", and client updates cannot be avoided. And again, > The problem with this is servers which are sending this expand-refs > tag have hidden certain namespaces from older clients. Those names > can't be seen by older git clients, unless the user does an upgrade. I do not think "generally hidden, but if you need to know you are allowed to peek" is much of a problem. You do not do that for regular refs, only for "on-demand-as-needed" type things. If we are going to make extensive use of notes on commits to give richer annotations, I suspect notes hierarchy could be hidden by default in a similar way. -- 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