Information regarding upcoming Gitlab Migration: clarifications

Ben Cooksley bcooksley at
Fri May 1 06:17:12 BST 2020

On Fri, May 1, 2020 at 4:38 PM Nate Graham <nate at> wrote:
> On 4/30/20 5:59 PM, Aleix Pol wrote:
> > El jue., 30 de abr. de 2020 a la(s) 18:15, Albert Astals Cid
> >> Am I the only person that just has all the repos on the same folder? I thought it was the common thing to do :?
> >
> > I do too
> Same here. kdesrc-build's default settings do this, and download all
> repos into ~/kde/src without any of the levels of hierarchy. This would
> seem to require unique repo names, no?

Not necessarily.

Git allows you to override the name that the local folder is called
when cloning, so there is no reason why we can't specify something in
the metadata to override the local name that the folder gets called in
your local checkout folder.
This would allow for example:

- frameworks/kcoreaddons on Gitlab continues to be called
'kcoreaddons' in your local checkout folder
- maui/dialer on Gitlab gets called 'maui-dialer' in your local checkout folder

This allows for the URLs on Gitlab to make sense, while simultaneously
allowing your local source checkout folders to continue to work in the
manner in which they do currently.
Note that we do not expect people to hit this in many cases - this is
about giving us the flexibility for the long term without imposing
unnecessary bureaucracy and limits on projects within the KDE

Automated tooling such as kdesrc-build and the proposed clone script
(that searches in namespaces) should be able to handle this without
much issue.
In the case of manually done clones, it is reasonable to expect people
to know what they're doing with their clones, and name them
appropriately in the event they have a collision.

Does this sound acceptable?

> The group categorization we've been discussing may be useful on the web
> UI for newcomers, but it has no value for your source checkout folder
> IMO, where it just makes it slightly more annoying to navigate from one
> repo to another.
> Nate


More information about the kde-core-devel mailing list