Julian Phillips <julian@xxxxxxxxxxxxxxxxx> writes: > That way you are not reliant on the user's tools following your rules. You misunderstood -- what implements the rules is on the repository side, not the end users' side. > I don't think it unreasonable to say that anything that is in a public > repository is public, and that the way to keep things private is to > not push them into a public repository. Or is it? I wouldn't have bothered to jump into the thread if this were about public repositories. You would not even need a separate namespace refs/bm -- you do not have to push that out. But that was not what Andy was talking about. > I understand that some people may wish to make their working > repositories public, but then there isn't any way we can say for sure > that things will remain private. Even if ls-remote was updated, an > older version would simply ignore the new "this is private" > configuration. You misunderstood. I am not talking about updating ls-remote. The update to upload-pack/update-server-info is done on the side of Andy's repository, not on the client side. > or simply expand the current push configuration to accept that syntax, > so that you can finely control which refs get pushed to the public > repo? You do not have to update anything on push side, as push just pushes what you tell it to, unless you say 'push --all', in which case you obviously mean all is all is all, so there is no need for exclude. - 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