[Kde-scm-interest] Layout #2 of Git repositories for KDE

[Johannes Sixt]

Thiago Macieira schrieb:
> Thankfully, we don't have to preserve history of the kdereview.git 
> supermodule. It's there just as a "mamma, look how I'm big now!" (= please 
> review this project).

IOW, *there*is*no* kdereview.git supermodule. There is only the directory on 
the server that serves as a container for the projects to be reviewed. Right?

> If the target is a submodule of KDE, then the project will be imported with 
> merge -s subtree (special case of copy-with-history) and the repository will 
> be abandoned.

I don't know if I understand you correctly. Are you thinking of having a 
project foo/ that will end up as kdelibs/foo/? That should better be a fork 
of kdelibs/ that introduces the new foo/. Or introduce foo/ as a submodule 
of kdelibs/.

> Actually, come to think of it, none of the supermodules need to have a correct 
> history, even KDE.git. Their only purpose in life is to allow easier checking 
> out of the submodules, as well as to provide a top-level CMakeLists.txt that 
> basically does:
> 
> 	macro_add_optional_directory(*)
> 
> So that people like me can build a manageable 10 or 15 modules, instead of 150 
> different applications and libraries.

I tend to disagree: You need supermodules, in particular KDE.git also for 
atomic commits that span modules. E.g. an API change in kdelibs that needs 
to propagate to kdebase etc. You will want to have that even in stable/.

-- Hannes