RFC: Top level git repository for all 57 Frameworks repositories

[nerdopolis]

On Tuesday, December 24, 2013 12:12:57 AM Alex Merry wrote:
> On 23/12/13 13:16, nerdopolis wrote:
> > Hi.
> > In my opinion the Frameworks split into 57 repositories could make it harder to for users to create build scripts around KDE Frameworks 5.
> > I can see why it had to be done, I heard it's so that they can be on separate release cycles.
> > 
> > 
> > There is a way to unify these Frameworks while keeping them in separate GIT repositories, using Git submodules.
> >  
> > I suggest a top-level repository, that uses has all 57 of the Frameworks repositories linked in with Git submodules.
> > QT5 already has a similar solution, and better describes what I mean:
> > https://qt.gitorious.org/qt/qt5
> > They have multiple components in separate repositories, but they have one repository that lets users build all of them as one, as all of the separate components are tracked together with Git submodules.
> > 
> > 
> > I created a proof of concept repository to test this idea with KDE Frameworks. I copied out some of the CMake files from the original kdelibs, and I linked the each of the frameworks to the appropriate folders with Git submodules. 
> > 
> > With only a few modifications in my build script, pretty much just changing the repository URL, and branch, and changing the way it handles submodules, I was able to fully build all of the Frameworks in the separate repositories.
> > 
> > I created it here, hopefully it will be of use to someone, or maybe even merged on Quickgit if it's good enough
> > https://github.com/n3rdopolis/kf5
> 
> Git submodules certainly have their uses, but the fact the top-level
> repository locks the submodules to specific commits has downsides as
> well as benefits.  Someone (or something) has to keep the top-level repo
> up-to-date.
> 
> Parsing kde_projects.xml from projects.kde.org (as kdesrc-build does) is
> probably a better approach for most build scripts.
> 
> Alex
> 
That is a disadvantage with Git submodules, but with Git 1.8.2 (I think it's 1.8.2 at least), you can tie the submodules to a particular branch,  
But you have to run the command: (adding the --remote flag)
git submodule update --remote 
to check out the branch for the submodule specified in .gitmodules, otherwise it uses the commit. (I already have all of the submodules currently using master in .gitmodules in that repo.)