On 5/16/08, skillzero@xxxxxxxxx <skillzero@xxxxxxxxx> wrote: > Why do git submodules require manually committing the submodule itself > to each super repository after something in the submodule repository > changes? Is there some reason the super repository can't just "link" > to the submodules by branch name? It seems that if the .gitsubmodules > also specified the branch to use: This is difficult but (contrary to what others might say :)) in my opinion it's worth fixing. Exactly how to fix it is an open question though. The main reason the simple approach you suggested (just link to a branch instead of a particular commit) isn't good is that it doesn't guarantee you always get the same version every time. If the supermodule links to submodule branch "foo" and makes supermodule commit 23abc918c, and someone later pushes to submodule branch "foo", then checking out commit 23abc918c in the supermodule would get the very latest submodule "foo", not the one you had when 23abc918c was created. Thus all sorts of bad things could happen. So I think it would be very bad if the supermodule automatically updated to the latest version of the submodule whenever you commit in the submodule. *However*, the other way around might be fine: if you commit in the supermodule, maybe it should commit in the submodule at the same time and link to that specific commit. I'm pretty sure that idea doesn't have any *fundamental* flaws, it's just got a lot of really tricky details that need to be worked out. I've seen some "recursive commit" and "recursive push" patches floating around, so people are actively working on this. One of the hardest things to deal with is where to auto-push submodules to (which remote? which branch?) when you push the supermodule. Have fun, Avery -- 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
