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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to