On Thursday 2006 November 30 12:16, Andreas Ericsson wrote: > > What is the "right" branch though? As I said above, if you're tracking > > one branch in the submodule then you've effectively locked that submodule > > to that branch for all supermodule uses. Or you've made yourself a big > > rod to beat yourself with everytime you want to do some development on an > > "off" branch on the submodule. > > Perhaps I'm just daft, but I fail to see how you can safely track a > topic-branch that might get rewinded or rebased in the submodule without > crippling the supermodule. Wasn't the intention that the supermodule has Who said anything but rebase/rewind? As it happens though, I don't see why you can't (it wouldn't be pleasant though). A rebase or rewind still leaves the original commit in the object database, so provided no one runs git-prune, there is no catastrophic failure. > a new tree object (called "submodule") that points to a commit in the > submodule from where it gets its tree and stuff? Is the intention that > the supermodule pulls all of the submodules history into its own ODB? If > so, what's the difference between just having one large repository. If > not, how can you make it not break in case the commit it references in > the submodule is pruned away? I certainly never suggested anything /but/ storing a submodule type that stores the commit. The current debate is about whether the supermodule should track HEAD or some defined branch in the submodule. > but then you're in trouble because the supermodule will have the same > files as all the submodules stored in its own tree. I'm confused. Could > someone shed some light on how this sub-/super-module connection is > supposed to work in the supermodule's commit objects? I don't really know, I only joined in to stand up against commit in the supermodule triggering commits in the submodule. That lead to me trying to get an understanding of how it would work. As far as I can see, the only way a submodule is any use is if it is always a submodule-commit-hash that is noted in the supermodule tree object. That means that the supermodule will only commit clean submodules. The rest is just UI to show something useful in the difficult cases when the submodule tree is dirty. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@xxxxxxxxx - 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