[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Gitlab Evaluation & Migration
From:       Milian Wolff <mail () milianw ! de>
Date:       2019-03-22 11:42:09
Message-ID: 2137832.LT0GVY1YHg () agathebauer
[Download RAW message or body]


On Donnerstag, 28. Februar 2019 07:02:03 CET Ben Cooksley wrote:
> On Thu, Feb 28, 2019 at 5:12 PM Michael Pyne <mpyne@kde.org> 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 <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.
> > 
> > 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.

Bye

-- 
Milian Wolff
mail@milianw.de
http://milianw.de
["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]