---- On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein <hein@kde.org> wrote ---- 
 > On 2/27/19 4:38 AM, Nate Graham wrote: 
 > > It's really pretty nice. But  Gitlab has a fork-the-repo-and-submit-a-merge-request workflow, so in steps 3 and 4, people without commit access won't just be able to start hacking with the source checkout that kdesrc-build downloads, or else they won't be able to push their branch to any remotes and create a Merge Request. 
 >  
 > No, this is not correct. 
 >  
 > When you have a local git repository (be it your own or a clone), it can  
 > interact with any number of remote git repositories. 
 >  
 > When you do `git clone <something>`, git automatically adds <something>  
 > as a remote named "origin" to the local repository. But what "origin"  
 > points to can be changed at any time, or other remotes with other names  
 > can be added for pushing too. "origin" is just a convention. 
 >  
 > I.e. someone can totally do this: 
 > 1. use kdesrc-build to clone stuff 
 > 2. git checkout -b feature to make a feature branch 
 > 3. hack 
 > 4. make a private fork on gitlab 
 > 5. push to their fork from the clone they've been working in 
 >  
 > It's not necessary to fork first and clone your fork to get started. 

Thanks Eike, that makes e a lot of sense. Going to the website to fork each repo for the first time still adds an additional manual step compared to the status quo, so it would be nice if we can get kdesrc-build so set up forks automatically. That would be really slick.

Nate