[Digikam-devel] Re: Git migration and submodules

[Andreas Pakulat]

On 21.12.10 21:50:20, Kåre Särs wrote:
> Hi,
> 
> Kate and Digikam seems to have similar problems to solve when it comes to the 
> git migration.
> 
> Below is an informative response to my idea to use submodules like it is 
> planned in Digikam.
> 
> On Tuesday 21 December 2010 17:55:44 Andreas Pakulat wrote:
> > On 21.12.10 15:54:23, Kåre Särs wrote:
> > > I have not used git much, but if I'm correctly informed, it is possible
> > > to create a 'superproject' that has submodules that point to different
> > > git repos.
> > > 
> > > Would this not solve the problem? Kate and kdelibs could point submodules
> > > to the same katepart repo with some added logic in the Kate to figure
> > > out if the kpart should be compiled...
> > > 
> > > I got the idea from the kde-imaging/digikam mailings list where they are
> > > discussing the move to Git.
> > 
> > As Ian said, submodules are anything but easy. In particular one needs
> > to be really careful during setting up commits in the parent repository
> > and even more careful when working inside a submodule (as usually its at
> > a specific revision and not on a branch-head. So comitting will not put
> > that commit into any branch).
> > 
> > We're using submodules at work for one project and its still something
> > we want to eliminate in the mid-term as we do mess up history in either
> > module from time to time and need to rebase stuff and force push to the
> > shared repository.
> > 
> > Oh, last but not least, the kde-scm list has long acknowledged that
> > submodules in git are not up to the task of grouping repositories for
> > KDE. Thats one of the main reasons we're now having a software on
> > projects.kde.org that allows arbitrary nesting of "projects".
> > 
> 
> Andreas: Can you give any links or information on the nesting software on 
> projects.kde.org?

The software hosting projects.kde.org is called redmine, you should be
able to find lots of information on it via the web. Or simply following
the "Help" link on projects.kde.org.

If you click on "Projects" on projects.kde.org you'll see the current
structure, which is similar to what we have in trunk/ today (with
playground, extragear, kdesupport and KDE). This is all just 'virtual',
the actual git repositories (as visible in gitweb.kde.org) are a
flat list. 

The structure on projects.kde.org will also be used to create the KDE SC
releases. So for example even if modules like kdeedu or kdegames are
split up into several git repositories, the KDE SC release will still
ship a kdeedu.tar.bz2 (at least thats the current plan as far as I
know) that assembles all of the sources of the various repositories.

In the same way its planned to supply special files for tools like
kdesrc-build to easily build kdeedu and other split-modules. 

I'm sure some of this has been written down in either the
GitKDEOrgManual on community.kde.org or on techbase.kde.org in the "plan
for git migration" page (not sure what the actual title is right now).

Andreas

-- 
Your temporary financial embarrassment will be relieved in a surprising manner.