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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

> 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.


--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]