Re: Composing git repositories

Am 31.03.2013 22:34, schrieb Ramkumar Ramachandra:

quoted

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

quoted

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.