Re: Composing git repositories

Thanks for taking the time and effort to review my thoughts.

Jens Lehmann wrote:

A
commit is the thing to record here because it *is* the perfect fit

Might be, but saying that doesn't help one bit.  I want to know why.

I want to improve the user experience
of submodules and don't care much in what language we achieve that.

You missed the point entirely.  If git didn't have a commit object,
would you use a special kind of blob and code around everything to
avoid fixing a more fundamental issue?

What happens when you rename "magit" to "foo" in that branch and want
to check out an older commit of the same branch? That is one of the
reasons why that belongs in to a checked in .gitmodules and not
someplace untracked.

Good point.  I learnt something new.

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?

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.  Let's just go
back to writing patches, and come back to this if and when I have a
full design.