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

[Thiago Macieira]

Em Monday 05 November 2007 15:47:33 Johannes Sixt escreveu:
> 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/.

Yes, I was thinking of that case. Sometimes you don't know ahead of time where 
your brand-new application will end up.

I would like to avoid introducing submodules inside kde modules (kdelibs, 
kdebase, etc.) because they don't feel like one single repository. In other 
words, either the repository contains code or it contains submodules -- never 
both (except the admin/ import, for KDE 3 history). This also means I don't 
like the plasma svn:external that is in amarok.

[Unless this is changed in Git so that they do. (i.e., git status, git diff, 
git annotate, etc., cross into the submodule as if it were part of the 
supermodule's tree, as well as crossing back out to the supermodule if you're 
inside the 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:
> >
> >       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/.

Yes, that's the reason and use of supermodules in Git today, aside from ease 
of checking out.

But that's not what I meant.

My point is that you don't check out KDE.git from KDE 2.x times because that's 
no longer developed. Even if you *did* want to check it out, you'd check out 
from releases/KDE.git, not from stable/KDE.git.

My worry when I raised this issue was that, after the repository got 
moved/renamed, the old commits would break. That will still happen, but it's 
not an issue because you should not be checking out old commits and trying to 
develop from there. 

Worst case scenario is when you branch off a commit that is before a rename: 
you'll have to update the submodule link. In any case, it's no worse than 
Subversion today.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20071105/013c46bc/attachment.pgp