Re: Composing git repositories

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 31.03.2013 22:34, schrieb Ramkumar Ramachandra:
>> 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).

>> 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.