Protected branches about forgefed HOT 2 OPEN

but this was an excellent explanation koala git can allow anonymous read/only access over HTTP for example - authentication is typically only required to modify (e.g. push)

there are a few important caveats that were implicit in this question that OP should be aware of firstly, the very notion of "protected branches" is a github invention - for one thing, this spec is intending to support a wide range of VCSs and clients, even raw patches; and not all VCS have "branches" - also, "protecting" branches is not a general development practice; so even if it were feasible, this would be a forge-specific niche-feature the second thing is that the web server and the git server are two entirely separate things - neither depends on or are necessarily coupled to the other - there is no way to represent a "protected branch" in git - that is a fiction that the git server must enforce locally with hooks based on it's own local permissions mechanism as maintained by it's local users the third thing is regarding authentication - when a user initiates a cross-server clone (aka "fork") the forge website (or whatever interface it exposes) plays no role in that, other than to send a request to the user's home-server requesting that it's user has initiated the action - then that user's home-server needs to log into the source git server to do the clone on the user's behalf - note that is the source git server, not the associated web server (they may be on entirely different machines) - off-hand, im not sure if it is even possible for the home-server to indicate which user on whoms behalf the clone is being requested - in any case, it could lie about that the git server would typically only filter on IP addresses and SSH keys; and neither of those would be associated with the user, but the home-server - so yes, it could specify which servers are allowed to checkout the code; but pushing code onto a server should only be allowed for it's local verified users - no one should want foreign users to have write access; and i doubt that any forge would implememnt it - if the web server wants to reject clones initialted by a foreign users with per-user granularity, the only chance it has is to reject the initial mouse click "at the front door" - it can do that, but as koala explained, there is nothing the protocol could do to assist, nor to insist, nor to prevent anything of the like "out in the cloud"