Re: git submodules and commit

From: Nigel Magnay <nigel.magnay@gmail.com>
Date: Jul 16, 2008, 14:03 UTC
Message-ID: <320075ff0807160703v3f16ff5bue722b760ad66488e@mail.gmail.com>
In-Reply-To: <487DF9BB.10107@viscovery.net>

On Wed, Jul 16, 2008 at 2:38 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:

Show 7 quoted lines

> Nigel Magnay schrieb:
>> P and S aren't distant projects, they're closely coupled.
>
> And I'm saying that submodules are designed for *loosely* coupled projects.
>
> It's no wonder that this tool is awkward to use in your workflow.
>

Ok in a sense. I don't think it's particularly clear from the documentation that this is a limitation of submodules though.

Given that
- The only way in git to separate out re-usable modules is by the use
of submodules
and
- It's a pretty common usecase for these submodules to be interrelated
and
- Looking over the list archives, it seems this is quite common complaint

"I really like the git submodule implementation, I just don't like how hard it is to work with"

 "The current behaviour strongly encourages me to avoid submodules
when I would otherwise like to use them, just to keep the rest of my
team members (who are not git experts) from going insane."

 "For my use case, I passionately dislike the fact that a submodule is
not updated automatically.  There's never a time when I don't want to
update the submodule.  The submodule is a very important piece of our
project and the super-project depends on it being at the right
version."

and
- All the technical capability is there, it's just the porcelain
that's causing the friction.
then
 would this not seem to be an area that could be improved? Even if it
were an optional mode of working?