Make contributing to a private repository easier #320

New Issue

GiteaMirror · 2025-11-02T03:18:26-06:00

GiteaMirror commented

2025-11-02 03:18:26 -06:00

Originally created by @strk on GitHub (Feb 3, 2017).

This is an idea for discussion about simplifying contributions to a private repository.
Currently for a contributor who wants to send a pull request for a private repository these steps are needed:

Fork the repository
Grant read access to the fork to anyone who have to review and can merge his contribution

I'm not sure if pull requests are allowed at all at the moment, because a user reported being unable to do so (maybe because made a member/contributor of the organization?).

Anyway my idea is to automatically create, upon forking a repository, a team representing "all the users who had read access to the repository being forked", and grant this new team read permission on the fork. The user forking the repository should be warned about the creation of such team so he can remove the permission if so willing. Or be given a choice at fork time...

Even better it would be if the team would be an actual "proxy" to the permissions in the original fork, so to follow changes in the original organization, but as I can envision such a thing could become very complex, a snapshot would be a great start already.

What do you think ?

@bkcsoft

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Originally created by @strk on GitHub (Feb 3, 2017). This is an idea for discussion about simplifying contributions to a private repository. Currently for a contributor who wants to send a pull request for a private repository these steps are needed: 1. Fork the repository 2. Grant read access to the fork to anyone who have to review and can merge his contribution I'm not sure if pull requests are allowed at all at the moment, because a user reported being unable to do so (maybe because made a member/contributor of the organization?). Anyway my idea is to automatically create, upon forking a repository, a team representing "all the users who had read access to the repository being forked", and grant this new team read permission on the fork. The user forking the repository should be warned about the creation of such team so he can remove the permission if so willing. Or be given a choice at fork time... Even better it would be if the team would be an actual "proxy" to the permissions in the original fork, so to follow changes in the original organization, but as I can envision such a thing could become very complex, a snapshot would be a great start already. What do you think ? @bkcsoft <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/41644380-make-contributing-to-a-private-repository-easier?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github). </bountysource-plugin>

GiteaMirror added the type/proposal label 2025-11-02 03:18:26 -06:00

GiteaMirror closed this issue

2025-11-02 03:18:27 -06:00

GiteaMirror commented

2025-11-02 03:18:27 -06:00

@lunny commented on GitHub (Feb 4, 2017):

The only way to contribute to a private is to join that repository. If you can fork that repository, so that you have read access to that repository.

@lunny commented on GitHub (Feb 4, 2017): The only way to contribute to a private is to join that repository. If you can fork that repository, so that you have read access to that repository.

GiteaMirror commented

2025-11-02 03:18:27 -06:00

@strk commented on GitHub (Feb 4, 2017):

@lunny: right, you obtain read access to the repository, you fork, but then the ones who are supposed to be pulling from your fork won't have read access to it (to the fork), unless an explicit action is taken by the contributor to grant those permissions. This is what this ticket is about. Making that explicit action easier or maybe not even needed by default.

What is not easy now is figuring out who needs to have read access to your fork, for example. You know you want the ones who have "merge" rights to read it, but more likely all the ones who do have "read" rights on the original repo (so to also include reviewers). It's probably a more rare use case that you want your custom changes (your fork) to be unreadable by the people who could read the original repo you forked from...

@strk commented on GitHub (Feb 4, 2017): @lunny: right, you obtain read access to the repository, you fork, but then the ones who are supposed to be pulling from your fork won't have read access to it (to the fork), unless an explicit action is taken by the contributor to grant those permissions. This is what this ticket is about. Making that explicit action easier or maybe not even needed by default. What is not easy now is figuring out *who* needs to have read access to your fork, for example. You know you want the ones who have "merge" rights to read it, but more likely all the ones who do have "read" rights on the original repo (so to also include reviewers). It's probably a more rare use case that you want your custom changes (your fork) to be unreadable by the people who could read the original repo you forked from...

GiteaMirror commented

2025-11-02 03:18:27 -06:00

@bkcsoft commented on GitHub (Feb 12, 2017):

@strk You can make a PR from your fork to upstream though... Upstream does not require read-access to your fork :)

@bkcsoft commented on GitHub (Feb 12, 2017): @strk You _can_ make a PR from your fork to upstream though... Upstream does not require read-access to your fork :)

GiteaMirror commented

2025-11-02 03:18:27 -06:00

@strk commented on GitHub (Feb 12, 2017):

Are you sure ? Did you try ? How could the "Files Changed" tab work ?
I think I only tried pulling the changes via commandline git because
the forker could not file a PR possibly due to being part of the
original team (I might have filed another ticket for that).

@strk commented on GitHub (Feb 12, 2017): Are you sure ? Did you try ? How could the "Files Changed" tab work ? I think I only tried pulling the changes via commandline git because the forker could not file a PR possibly due to being part of the original team (I might have filed another ticket for that).

GiteaMirror commented

2025-11-02 03:18:28 -06:00

@bkcsoft commented on GitHub (Feb 12, 2017):

Where the integration-test for this? :trollface:

@bkcsoft commented on GitHub (Feb 12, 2017): Where the integration-test for this? :trollface:

GiteaMirror commented

2025-11-02 03:18:28 -06:00

@strk commented on GitHub (Feb 13, 2017):

I've created a private repo and made you a collaburator
with read access, please send a PR: https://try.gitea.io/strk/private

@strk commented on GitHub (Feb 13, 2017): I've created a private repo and made you a collaburator with read access, please send a PR: https://try.gitea.io/strk/private

GiteaMirror commented

2025-11-02 03:18:28 -06:00

@bkcsoft commented on GitHub (Feb 14, 2017):

@strk Done 🙂 https://try.gitea.io/strk/private/pulls/1

@bkcsoft commented on GitHub (Feb 14, 2017): @strk Done 🙂 https://try.gitea.io/strk/private/pulls/1

GiteaMirror commented

2025-11-02 03:18:28 -06:00

@strk commented on GitHub (Feb 16, 2017):

Sorry, I merged with the button before trying to do it on commandline.
Want to send another ? :)

@strk commented on GitHub (Feb 16, 2017): Sorry, I merged with the button before trying to do it on commandline. Want to send another ? :)

GiteaMirror commented

2025-11-02 03:18:28 -06:00