Re: [RFC] Submodules in GIT

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

You were proposing to create an extra object containing some random value
that is disconnected from the repo.

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.

quoted

Is that commit in the submodule or the supermodule?

It's in BOTH.  That's why it's a *sub*module.

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

-- 
Dr Andy Parkins, M Eng (hons), MIEE