On Sun, Jan 20, 2013 at 02:08:32PM -0800, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > Jeff King <peff@xxxxxxxx> writes: > > > >>> [uploadPack] > >>> hiderefs = refs/changes > >> > >> Would you want to do the same thing on receive-pack? It could benefit > >> from the same reduction in network cost (although it tends to be invoked > >> less frequently than upload-pack). > > ... > > As I said, I view this primarily as solving the cluttering issue. > > The use of hiderefs to hide these refs that point at objects I do > > not consider belong to my repository from the pushers equally makes > > sense as such, I think. > > Now that raises one question. Should this be transfer.hiderefs that > governs both upload-pack and receive-pack? I tend to think the > answer is yes. Yes, that is what I was getting at (and it should have individual hiderefs for each side that override the transfer.*, in case somebody wants to make the distinction). > It may even make sense to have "git push" honor it, excluding them > from "git push --mirror" (or "git push --all" if some of the > branches are hidden); I haven't thought things through, though. That is harder, as that is something that happens on the client. How does the client learn about the transfer.hiderefs setting on the remote? It has to be out-of-band, at which point calling it by the same name has little benefit. -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