[oll-user] Repository organization

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

Hi,

this is the first email separating issues from a recent thread
(http://sourceforge.net/mailarchive/forum.php?thread_name=5147033D.9030301%40openlilylib.org&forum_name=openlilylib-user)
into separate topics.
I'd be glad if we could keep them separate as much as possible ;-)

Joe is highly in favor of separating our stuff into separate Git submodules.
The most important statements are possibly the following (you can find 
more in the thread):

> but I don't see the point in having
> one-repo-to-rule-them-all_unless_  done via submodules -- the separation into 3
> different projects is quite correct IMO, as each part is clearly independently
> useful (or at least, such dependencies as exist are one-way only).

> I think you need to think of it like this: users who only want to_use_  one or
> more of the parts may operate off archived releases, but what about users who
> only want to_work_  on one of the parts?  It's really not clear to me why
> someone who wants to work solely on lilyglyphs (say) should have to pull in
> OLLib or the manuals.
Basically I fully agree with that POV, as the sub-projects really are quite independent conceptually, and I agree that the interdependence of the current design is based on my perception of the 'whole' which is far from being carved in stone.

However, I'm still somewhat insecure about how the submodule approach is actually manageable.
 From trying to understand the docs and reading blog posts I have two questions:

1)
A submodule isn't just a Git repository living in a subdirectory. Instead, a submodule points to another remote repository, so this seems to mean that we have (e.g.) lilyglyphs as a subdirectory/submodule within openlilylib _and_ as  standalone repository.
I understand this set-up for the usual examples of a third-party library, but I don't really see how this is natural for our case.

2)
I have read that it is comparably 'simple' to get the repo/submodule constellation out of sync and even corrupted (if one part points to a commit that the other part hasn't pushed etc.).
How complicated does a working policy have to prevent this? And how complicated is it to recover from such situations?
Instead of an explanation I would also accept statements like "I know this works smoothly, and you'll see it when it is running".

If that's actually manageable, I'd happily accept to split the main repository in as many submodules as seem appropriate. But I'd be glad if someone could guide me through the process of doing so without me having to learn everything from scratch.

Best
Urs