progit
Distributed Git > Integration-Manager Workflow - refinement
https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows Line number 37 to 63
cit.: ..each developer has write access to their own public repository and read access to everyone else’s.
So this workflow property is pointed out however chapter section does not illustrate that to be in use. Reader will ask him/herself what is it good for.
Just after the figure we say this:
This is a very common workflow with hub-based tools like GitHub or GitLab, where it’s easy to fork a project and push your changes into your fork for everyone to see.
Whether you know it or not, you're using this workflow right now. If I want to pull one of your PR branches onto my own machine, I'm playing the part of the integration manager, and I need read access to your repo in order to fetch it.
This is a pretty important workflow, since it represents most of the activity in public repos on GitHub, so we can't remove this section. Are you suggesting we should give a more-detailed example of how it works?
Whether you know it or not, you're using this workflow right now. If I want to pull one of your PR branches onto my own machine, I'm playing the part of the integration manager, and I need read access to your repo in order to fetch it.
That's nice : ) Please notice your reply addresses bit different point as that one in finding here. Latter one is talking about developers to have read access to other's public repos. You are talking about integration manager. Kindly apologize for being rude but I am not sure your point is approaching raised point.
I am not so far to make suggestions. I just figured this point out. Maybe remove "and read access to everyone else's", or maybe to show application of this property, maybe yet another fix. In the meantime I learned for new questionable points to make PR without raising issues and to raise issue if no approval proposal on hand.
The reason the integration manager needs read access to all the contributors' repositories is so that they can pull from them. For example: I can't merge in your commits if I don't have access to read them from your repository.
There is absolutely no issue with integration maintainer's read access to all contributors' public repositories, at far as my humble opinion is concerned. This thicket addresses quite different point. cit.: ..each developer has ... read access to everyone else’s.
Aha, I see what you're getting at. I suppose this isn't technically required; the only person who requires read access to a contributor's repo is the integration manager. In practice it's almost always a bunch of public repos, though; if contributors A and B both fork the IM's public repo, their forks are public as well, so A and B can both read each other's repos.
I'm having a hard time writing a sentence that's more correct but less clunky. This is as good as I can do:
[...] a workflow where each developer has their own repository, where that developer has write access, but the integration manager has only read access.
[...] a workflow where each developer has write access to their own repository, but the integration manager has only read access.
These both seem unnecessarily specific to the integration manager, and it takes a few extra steps to lock down your permissions to make it exactly fit this.
Fortunately details about by which mimics all developers' public forks enable read access for all developers are out of this sub-chapter's scope and do not need to be mentioned in text : ) The fact every developer's public repository to be readable by each other developer is in this chapter neither of significance nor is being used in workflow elaboration. So let's the text be less obscure by reducing redundancy.