Am 28.06.2011 22:43, schrieb Junio C Hamano: > Heiko Voigt <hvoigt@xxxxxxxxxx> writes: > >>> What if >>> >>> (1) you are binding somebody else's project as your own submodule, you do >>> not make any local changes (you won't be pushing them out anyway), >>> and you do not have remote tracking branches in that submodule >>> project? >> >> In this scenario the superproject can not be cloned that way that it >> would contain the submodule right? I would consider this a rather exotic >> way to work since pushing means to share your work somehow. > > Sorry, I don't follow. Isn't this the classical example of an el-cheapo > router firmware project (i.e. superproject) binding unmodified Linux > kernel project as one of its submodules without you having any push > privilege to Linus's repository, which was one of the original examples > used in the very initial submodule discussion? Yes, but if you push a version to el-cheapo upstream containing a Linux submodule commit not contained in Linus' repository (because you made some changes yourself), that won't be cloneable from upstream el-cheapo by anyone else. This is what this check makes you aware of, and the best practice here IMO is: make your own fork of Linus' repo (on github or someplace similar) and then you do have the push rights. (This is what we do where I work for every repo we don't have push access to and it solves this problem nicely. And in fact this is pretty much the same I do for a stand alone repo - like Git - I don't have push access to but want to publish my changes for: I make a fork that gives me push rights and allows me to share my work) >> This check is solely meant as a convenience security measure. It should >> and can not enforce a tight check whether a superproject (including its >> submodules) can be cloned/checked out at all times. But it ensures that >> a developer has pushed his submodule commits "somewhere" which is enough >> in practice. > > I am not entirely convinced but if this would catch more than 80% of > casual mistakes, it would be good enough. I was hoping that somebody may > come up with an idea that would work even in case (3), though. My impression is that we would catch more than 80% (but I admit that I might be influenced by the way we use submodules). Anyways, maybe the solution for (3) is to only take the default remote into account and to ignore the others? (Because that's the one most users will initialize from the .gitmodules of the superproject) -- 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