Re: [RFC 2/2] Don't push a repository with unpushed submodules

Am 28.06.2011 22:43, schrieb Junio C Hamano:

Heiko Voigt [off-list ref] writes:

quoted

quoted

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)

quoted

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)