Re: [oll-user] Call for initial feedback

[Urs L. <ul...@op...>]

On Wed, 20 Mar 2013 17:11:53 +0100
Janek Warchoł <lem...@gm...> wrote:

> 2013/3/20 Urs Liska <ul...@op...>
> 
> 
> > I like tinkering with git and i think i could learn how to merge
> > repositories.  However, maybe git submodules would be a correct answer?  A
> > submodule is just a repository inside another repository, so that we could
> > have a big repo containing all projects, while all of them would remain to
> > be separate repos.
> >  I don't know how well that plays with SourceForge, however.
> >
> > Hm, for some reason I don't really know I'm 'scared' by Git submodules.
> > The documentation on SourceForge doesn't mention submodules, but I don't
> > know if there are special needs for that on the server.
> > I think I will look in the official Git docs and get a better idea what
> > submodules really are.
> >
> 
> I have a bit of experience with them and they seem to be pretty
> straightforward.  I was even able to debug a corrupted git repository which
> contained a submodule, as you can see here:
> http://stackoverflow.com/questions/14797978/git-recovery-object-file-is-empty-how-to-recreate-trees
> (that was really awesome!  I felt like a pro when i had finished ;-) )
:-)

I have just read the submodules chapter in the progit book, and it seems it isn't the best solution.
First, a submodule is a repository with a different remote (i.e. pull in another repository to use and manage it within the main repository). So we'd have to keep the other remote repositories anyway (IIUC). Second, the book issues some warnings about having to be careful not to break things when working in submodules.

For my taste this rather looks like keeping the structure as it is or managing to merge the repositories and maintain them as one.

Best
Urs

> 
> best,
> Janek