Re: [RFC] Submodules in GIT

On Friday 2006 December 01 11:10, Sven Verdoolaege wrote:

Right, I think I've finally understood what Martin (and you) are proposing. You want every commit in the submodule to be propagated up to the supermodule as well. Okay.

I don't think it's right, but at least I understand.

It seems wrong because it's making commits in the supermodule that aren't commits to do with that project. In my libxcb example; why should every project use libxcb in have to store the entire history of libxcb? When examining the supermodule history, I won't care about how libxcb got to the state its in, and it's just noise in the supermodule history. What if I use 10 submodules, the supermodule history won't show you anything useful - it's just unrelated submodule commits.

It gets worse, this is why I was asking for more detail: this commit that you're storing in the supermodule. It's the same commit as is in the submodule? What would the parent commit of that commit be? It has to be the same in both, because the commit-hash forces it to be.

The only possibility would be that it's NOT the same hash in both, because the parents in the supermodule are inapplicable to the submodule, and the parent in the submodule is independent from the supermodule. That means you have to store two commits: one for the submodule commit and one for the supermodule commit. So what are you going to write in the supermodule commit? Answer: a submodule commit hash - exactly as I said.

If it's in BOTH then the supermodule is a normal git repository. You aren't tracking the submodule, you're just including it en masse. Using semantics to justify a position isn't a very strong argument, calling it a "sub" module is just an easy bit of naming for us to hang the discussion on, it isn't necessarily a mathematical subset and superset.

Andy