On Wed, Feb 06, 2013 at 11:17:06AM -0800, Junio C Hamano wrote: > Let me help unconfuse this thread. > > I think the series as 8-patch series was poorly presented, and > separating it into two will help understanding what they are about. > > The first three: > > upload-pack: share more code > upload-pack: simplify request validation > upload/receive-pack: allow hiding ref hierarchies > > is _the_ topic of the series. As far as I am concerned (I am not > speaking for Gerrit users, but am speaking as the Git maintainer), > the topic is solely about uncluttering. There may be refs that the > server end may need to keep for its operation, but that remote users > have _no_ business knowing about. Allowing the server to keep these > refs in the repository, while not showing these refs over the wire, > is the problem the series solves. > > In other words, it is not about "these are *usually* not wanted by > clients, so do not show them by default". It is about "these are > not to be shown, ever". > > OK? Right. I am not opposed to this series, as it does have a use-case. And if it helps Gerrit folks or other users unclutter, great. The fact that I could throw away the custom receive.hiderefs patch we use at GitHub is a bonus. If people want fancier things, they can do them separately. _But_. As a potential user of the feature (to hide refs/pull/*), I do not think it is sufficiently flexible for me to use transfer.hiderefs (or uploadpack.hiderefs). We use "fetch" internally to migrate objects between forks and our alternates repos. And in that case, we really do want to see all refs. In other words, all fetches are not the same: we would want upload-pack to understand the difference between a client fetch and an internal administrative fetch. But this feature does not provide that lee-way. Even if you tried: git fetch -u 'git -c uploadpack.hiderefs= upload-pack' the list nature of the config variable means you cannot reset it. This isn't a show-stopper for the series; it may just mean that it is not a good fit for GitHub's use case, but others (like Gerrit) may benefit. But since refs/pull is used as an example of where this could be applied, I wanted to point out that it does not achieve that goal. -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