Re: Composing git repositories

From: Jens Lehmann <jens.lehmann@web.de>
Date: Apr 1, 2013, 09:50 UTC
Message-ID: <5159585A.3060907@web.de>
In-Reply-To: <CALkWK0k=g3iFjmpUQA1VkuH2kZsVX1_Hpo=LZ7CuotwHz_1++g@mail.gmail.com>

Am 31.03.2013 22:34, schrieb Ramkumar Ramachandra:

Show 5 quoted lines

>> Are you aware that current Git code already stats all files across
>> all submodules recursive by default? So (again) no problem here, we
>> do that already (unless configured otherwise).
> 
> I didn't know that.  Why does it do this?

To show the user work tree changes inside the submodules too. It was really easy to forget to commit accompanying submodule changes when preparing a superproject commit before that (and that broke quite some builds at my $dayjob until we fixed that).

Show 14 quoted lines

>> Guess what: submodules are the solution for a certain set of use
>> cases, and tools like subtree are a solution for another set of
>> use cases. There is no silver bullet.
> 
> That's the core of your argument: submodules already solve what it
> was meant to, and we can't get it to solve a larger class of problems.
>  In other words, you're implying that it's impossible to build a tool
> that will be able to compose git repositories in a way that solves a
> very large class of problems.  I don't see conclusive proof for this,
> so I have to disagree.
> 
> To summarize, everyone seems to be elated with the current state of
> submodules and is vehemently defending it.  I'm a little unhappy, but
> am unable to express my discontent in better prose.

I just think it is too early for the "let's do things differently and redesign stuff" phase. Before doing that we have to clear up the things that currently don't work for you or are confusing you about submodules and see if they are already solved (which could lead to a documentation update) or what it would take to fix them using current submodule infrastructure. I have the strong feeling that after we did that, no design changes are necessary anymore.