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

Heiko Voigt [off-list ref] writes:

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?

How about not doing the is-pushed check when the submodule has no
remotes? If we assume that only people having remote tracking branches
want to share them via push this would allow your usecase.

Yes, that would reduce the false positive; same for (2).

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.