On Sat, Mar 23, 2019 at 12:42 AM Milian Wolff wrote: > > On Donnerstag, 28. Februar 2019 07:02:03 CET Ben Cooksley wrote: > > On Thu, Feb 28, 2019 at 5:12 PM Michael Pyne wrote: > > > 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)? > > > > The API for both EE and CE is identical, except for the functionality > > that is dependent on the edition of EE it is available in (which is > > only enabled if you are using that edition) > > With regards to credentials, you would need to give it an API Token yes. > > > > In terms of server load, it would be nice if the setup of forks was > > still something the developer had to initiate rather than being done > > automatically for every repository touched by kdesrc-build (I say this > > mainly as if we had 50 people fork just half of the mainline > > repositories we have, that's ~450GB of space used up - a massive > > scalability issue) > > Are you sure about this? Isn't gitlab using something like `git-new-workdir` > internally to save on the disk overhead? If not, then request it, that would > be an obvious optimization opportunity. I haven't checked, but at first glance it doesn't seem to do this (which would make sense, because you're actually able to have multiple Gitaly instances to store repositories for a single Gitlab instance). In any case, i'd rather that we used fork in a manner that makes sense rather than trying to optimise for something that ends up creating thousands of repositories which are never used. We should only be creating forks / repositories which are actually going to be used. > > Bye > > -- > Milian Wolff > mail@milianw.de > http://milianw.de Regards, Ben