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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html