Re: [oll-user] Call for initial feedback

[Joseph R. W. <jos...@we...>]

On 03/28/2013 05:59 PM, Urs Liska wrote:
> Why this overhead of having a remote repository and its submodule 'mirror'?
> And the caveats I read about in the progit book don't look reassuring 
> either.

Not familiar with the remarks in the progit book, but the logic of submodules as
I see it is that you can divide your codebase into separately versioned parts
which can then be incorporated into multiple different projects.

In the example I gave you, the LLVM-based D compiler, it makes sense to have the
standard library as a submodule because that way contributors on different D
compilers can contribute to and pull from the latest version of that standard
library regardless of what compiler they're personally using.

> Not really problems, its rather the complexity of the amount of repos.
> An example: If I work on, say, the manual for 'musicexamples' I may run 
> into updating the stylesheet package. If everything is in one repository 
> I will surely notice the need for committing this change, at least if I 
> want to power down the computer and see that git status isn't clean.

Wouldn't that kind of issue suggest that your repos are improperly modularized?

For example, if an individual tutorial needs a stylesheet change, it might make
sense to allow tutorials to have custom local stylesheets that are used
alongside the global one.  And if, reviewing the merge of a tutorial patch,
there is a stylesheet change, it could be consciously decided to make that
change to the global stylesheet instead.

Put it another way -- if you have to make changes to the global stylesheet
often, then your global stylesheet needs rethinking anyway.  Preventing you from
habitually making stylesheet changes along with tutorial changes is probably a
good way to enforce good discipline of design.

> If the files were in separate repositories I would have to take care 
> myself that I don't forget to update also the repo with the stylesheet in.
> Or: Each time I have to change a computer I have to go through all the 
> repos to check if there are changes to be fetched and merged (or 
> rebased). That's quite tedious and requires a fair amount of 
> concentration in order not to omit a branch, for example.

It _should_ be as simple as git pull, git submodule update -- one more command
than you have to run anyway.

> Maybe you're right. But: As it is now I have to tell the contributor: 
> "clone the repository and make sure that LaTeX finds this folder and 
> LilyPond finds this folder. You may have stuff there that you don't 
> need, but you get everything you need with one clone." If there were 
> smaller chunks I'd have to say: "You may clone the module you want to 
> work on, but you will have to download and install the musicexamples and 
> lilyglyphs packages in order to compile the docs.

Well, you should still be able to do that with a master project and submodules.
 But if you're talking about a manual or a tutorial it's clear that you have a
strong dependency that requires everything.  If you're talking about just
contributing to lilyglyphs, that _could_ be largely independent of everything
else, if you design things right.

For example, a lot of your sense of dependency between docs and code/LaTeX
packages seems to stem from your concept of docs as a large-scale manual.  But
if instead you have micro-documentation for the individual toolboxes and
packages (as you see with the D standard library), you shouldn't need that
strong interdependency.  Then you can still _have_ the large-scale manual, but
as a separate project that builds on top of the micro-docs.