On Friday 2006 December 01 09:33, Andreas Ericsson wrote: > True, but this makes one repo of the submodule special. Let's say you > have this layout In a way, but it's information that doesn't need to be transmitted. > mozilla/.git > mozilla/openssl/.git > mozilla/xlat/.git > > Now, we can be reasonably sure that the 'xlat' repo is something the > mozilla core team can push to, or at least we can consider the core repo > owners an official "vendor" of tags for the submodule repo. I'm fairly > certain openssl authors won't be too happy with allowing the thousands > of projects using its code to push tags to its official repo though. No need, when cloning a supermodule, it will make those special tags automatically in the submodule repo. They are only there to prevent prune from destroying those referenced commits after all. If the submodule is cloned directly, they aren't needed anyway, and those objects won't be part of the dependency chain so wouldn't be downloaded. > Now that I think about it more, I realize this is completely irrelevant > as the ui can create the tags in the submodule with info only from the > the supermodule, which means the submodule repo will only be special if > it's connected to the supermodule. We just need a command for creating > those tags in the submodule repo so people who use the same submodule > code for several projects can use the alternates mechanism effectively. Is that even necessary? git-clone of a supermodule will make those tags automatically. If a submodule was alternative-cloned into a different supermodule, well then THAT supermodule would make the right tags for itself. Ah, I think I see what you mean now though, a method would be needed for creating those tags if we managed to manually get a submodule repository in to the supermodule - then supermodule-clone wouldn't have run. Perhaps they could be checked for at commit time and recreated then? 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