[Kde-scm-interest] Layout #2 of Git repositories for KDE
j.sixt at viscovery.net
Mon Nov 5 15:47:33 CET 2007
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
> 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:
> 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/.
More information about the Kde-scm-interest