Re: GSOC proposal

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 25.03.2011 11:06, schrieb Fredrik Gustafsson:
> On Thu, Mar 24, 2011 at 04:47:41PM -0700, Junio C Hamano wrote:
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>
>>>> == Preventing false "pointers" ==
>>>> It's far too easy to push a gitrepo pointing to a submodule version that
>>>> is not existing on the server. Prevent this by checking for available
>>>> submodule versions before acceptingt the push.
>>>
>>> Yes, requiring to force such a push is an issue raised quite often (I
>>> think addressing this issue would be a good starting point for people
>>> who want to get involved in enhancing the submodule experience).
>>
>> You need to be careful, though.
>>
>> That check can only be sanely done at a hosting site that hosts _both_ the
>> superproject and the submodule repositories.  It might make more sense to
>> have this check on the side that pushes, which by definition should have
>> both superprojet and the submodule.  Fail, or prompt to confirm, a push
>> from the superproject when it is detected that the submodule commits bound
>> to the commits in the superproject have not been pushed out.
> 
> I can see three different ways of doing this:
> 1. the reciever (server) checks for available submodules before
> accepting a commit
> 
> 2. the sender checks for available submodules on the server before
> sending a commit.
> 
> 3. each submodule contains a flag that tells if the last command was a
> commit or a push. The core-repository wont allow a push if one (or more)
> submodules has a commit as "last command".
> 
> Although alternative 1 is the only one that is certain of preventing the
> problem with "false pointers", it has several other drawbacks. I believe
> that alt. 3 is the proper way of handling this in git. Although we
> doesn't guarantee a sane server-repo we does prevent the client from
> doing stupid things by mistake.

I concur with Junio and am in favor of the following solution, as I
think we already have all the information needed present on the side
that pushes:

Before doing a push in the superproject collect all submodule commits
that are recorded in the commits to be pushed out to the superproject's
remote. Then check that they all are contained in at least one remote
ref of the submodule they are recorded for. If not, error out and tell
the user he should push the submodule first or has to use the "-f" flag
to force the push if he really knows what he is doing. Commits of those
submodules that aren't checked out are ignored.

This approach would achieve the goal you stated in your last sentence,
which me thinks is a sane thing to do.