On Wed, Feb 27, 2019 at 03:15:58PM -0700, Nate Graham wrote: > ---- On Wed, 27 Feb 2019 12:12:55 -0700 Eike Hein 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 `, git automatically adds > > 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. That would be slick. I wonder if Gitlab exposes an API for that (ideally something that doesn't involve kdesrc-build having to store your creds)? Potentially this API https://docs.gitlab.com/ee/api/projects.html#fork-project (though it's documented for EE not CE)? Regards, - Michael Pyne