From: Junio C Hamano <hidden> Date: 2016-06-15 22:51:31
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.
From: Fredrik Gustafsson <hidden> Date: 2016-06-15 22:51:31
On Tue, Jun 28, 2011 at 01:43:18PM -0700, Junio C Hamano wrote:
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.
There's ways to do a "better" check, but only(*) if the client communicates
with the server. This is expensive and doesn't make any sense to do for
the error we're trying to prevent here, forgetful developers that
forgotten to push a submodule.
A design goal for this check has been to make it just a client side
check.
I do not have a % value of how usual this fault is. I do know that
developers being introduced to submodules that I know of tends to
forget this (and so do I occasionally).
* According to what I found out. If there's a better solution I would of
course be very happy.
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iveqy@iveqy.com
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)
Hi,
On Tue, Jun 28, 2011 at 01:43:18PM -0700, Junio C Hamano wrote:
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?
But in such an example the Linux submodule (if used with git submodule)
would have remote tracking branches even though they are not directly
pushable.
Cheers Heiko