But without read access, the only way to merge the changes is to use the GitLab UI. Having read access to at least the source branch of the pull request makes it possible to merge using git and even do a fast-forward merge or rebase if required (of course with the author's consent).
And with dev branches on the main repo, the developer has 2 places to push changes - his/her own fork and also the corresponding dev branch of the main repo. This is okay, but the permissions of GitLab make it very much inflexible and unconfigurable imho. On Sunday, 11 January 2015 15:04:25 UTC+5:30, Daniel Le Berre wrote: > > Take for example a current merge request on gitlab: > https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/275 > > When you fork a project on gitlab, you keep a reference to the original > project. > > Thus, when you create a merge request with your changes, you provide just > a diff with the changes against a particular branch of the centralized > repos. > > There is no need for the main repos owner to have access to the developer > own fork to test the merge request. > > Daniel > Le 11/01/2015 10:13, L Guruprasad a écrit : > > Also, how does a master of a group who handles and merges merge request, > clone the repo from which the merge request is sent, so that he can test > the code changes before merging it? Right now the master of the group > cannot read the source repo of the merge request, unless the developer > explicitly gives each master/developer user read access to his fork. > > Bitbucket provides a workflow where developer users of a group can fork > repos within the group's namespace and all the members of the group have > read access to all the repos in the group including the fork. > > This way it is easy to clone the developer's fork locally and test out the > changes before making review comments or merging the changes. It also > doesn't require polluting the main repository with branches for each > developer when the whole purpose of forking is to have separate work areas > for each developer. > > On Sunday, 11 January 2015 14:22:37 UTC+5:30, L Guruprasad wrote: >> >> It is not possible for the master/owner level user to create forks for >> each user or transfer it when they create forks in their namespaces when >> the number of developers is large. >> >> Okay so assuming developers have to fork the private repo in their own >> namespace, how to ensure that the other members of the group have read >> access to the fork of the developer so that they can follow changes and >> when there is a merge request they can clone the repo to their computers >> test it out before giving review comments or merging it? >> >> Please suggest ways. >> >> On Sunday, 11 January 2015 14:16:47 UTC+5:30, Daniel Le Berre wrote: >>> >>> When you fork a project, you can choose a group namespace if you are >>> the owner of the group. >>> >>> According to the permission page, you need to be master or owner to >>> create a project in a group. >>> >>> So I suppose that the role of developer is not sufficient in your case. >>> Try with master. >>> >>> Cheers, >>> >>> Daniel >>> >>> Le 11/01/2015 09:41, L Guruprasad a écrit : >>> >>> I saw from the GitLab changelog that from version 7.6.0 it is possible >>> to fork repositories under a group namespace. This is particularly helpful >>> when there is a group for an organization and the developers want to have >>> their forks in the group namespace so that everyone in the group can access >>> the forks. >>> >>> So to test this, I created a group and added 2 users to the developer >>> role. Then as one of those 2 developer users when I try to fork one of the >>> group's repositories, it lists only the namespace of that user and not the >>> group namespace of which the user is part of. >>> >>> So how to fork repos within the group namespace? >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "GitLab" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/gitlabhq/05daf9b6-ddb8-42a7-b1ed-cb3df20e78c6%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/gitlabhq/05daf9b6-ddb8-42a7-b1ed-cb3df20e78c6%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- > You received this message because you are subscribed to the Google Groups > "GitLab" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/gitlabhq/084ded25-663a-4722-88bf-4264db3172cd%40googlegroups.com > > <https://groups.google.com/d/msgid/gitlabhq/084ded25-663a-4722-88bf-4264db3172cd%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "GitLab" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/gitlabhq/24f6c505-924a-471b-9608-50ad86da29ad%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
