Thanks for taking the time and effort to review my thoughts.
Jens Lehmann wrote:
> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html