We use the "Integration Manager" workflow listed on the same page - 
http://git-scm.com/book/be/v2/Distributed-Git-Distributed-Workflows#Integration-Manager-Workflow.
 
And here is what steps 5 and 6 say:

* The maintainer adds the contributor’s repo as a remote and merges locally.
* The maintainer pushes merged changes to the main repository. 

This is not possible even with way GitLab has implemented 'fork to group'.

On Sunday, 11 January 2015 14:54:40 UTC+5:30, Daniel Le Berre wrote:
>
>  Well, at some point, you have a unique product that ships, so it is 
> easier if you have a central repos for that product, for continuous 
> integration and code inspection for instance.
>
> But there are many ways to organize you workflow. 
> http://git-scm.com/book/be/v2/Distributed-Git-Distributed-Workflows
>
> Daniel
>
> Le 11/01/2015 10:15, L Guruprasad a écrit :
>  
> Why pollute the main repository with branches for dev contributions, when 
> the whole purpose of making forks is to allow a separate sandbox for each 
> developer?
>
> On Sunday, 11 January 2015 14:40:36 UTC+5:30, Daniel Le Berre wrote: 
>>
>>  [I am an old user of centralized revision systems so I may not use git 
>> properly.]
>>
>> Why not have a centralized repos forked by each developer with dev 
>> branches for testing developer contributions?
>>
>> See e.g. https://about.gitlab.com/2014/09/29/gitlab-flow/ for the way 
>> the gitlab team is working.
>>
>> Daniel
>>
>> Le 11/01/2015 09:52, L Guruprasad a écrit :
>>  
>> 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].
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/gitlabhq/9e250f9a-788e-4232-9625-ab12188e1f48%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/gitlabhq/9e250f9a-788e-4232-9625-ab12188e1f48%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/637b2fdc-e779-401c-a037-c46ddcfc9931%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/gitlabhq/637b2fdc-e779-401c-a037-c46ddcfc9931%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/074e38ee-1b01-4032-bd64-5e931378fe66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to