Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 15, 2016, 18:02 UTC
Message-ID: <xmqqwpidniry.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kZLdsKcf0t=dDB24VVe+V=uqQCW_VNQwSJ638m5Keu2nQ@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 23 quoted lines

> On Thu, Sep 15, 2016 at 6:02 AM, Yaroslav Halchenko <yoh@onerussian.com> wrote:
>>
>> If e.g. you just 'git add' a subdirectory which is a git repository, git
>> adds it as a subproject but doesn't initiate any entry in .gitmodules
>> since it is the job done by submodule and git core itself is
>> agnostic of those beasts.
>> ...
>> $> git submodule
>>  cc6a09ac06c13cf06b4f4c8b54cda9a535e4e385 ds000001 (2.0.0+4)
>>  0a9f3b66e06a2137311a537b7377c336f1fb30ad ds000002 (1.0.0-3-g0a9f3b6)
>>  9da7e4f4221699915645ac2003298c6aba2db109 ds000003 (1.1.0+4)
>>  fe16cacb5cb9b4d53c50e498298fab182500e147 ds000005 (2.0.0+3)
>>  6898d99ff3ba26880183ed3672a458a7fcde1737 ds000006 (2.0.0+2)
>>  bbd10f634fe87e9d5853df3a891edbdb18cda7f9 ds000007 (2.0.0+3)
>>  138e6730193c0585a69b8baf5b9d7a4439e83ecc ds000008 (2.0.0+2)
>>  ddf3a4cf7ce51a01a664e6faff4b8334b8414b1f ds000009 (2.0.1+1)
>>  7fa73b4df8166dba950c7dc07c3f8cdd50fca313 ds000011 (1.0.0-5-g7fa73b4)
>> fatal: no submodule mapping found in .gitmodules for path 'ds000017
>>
>> which then stops without even looking at other submodules.
>>
>> I think it would be more logical to make it a 'warning:' not a 'fatal:' and
>> proceed.

Making "git submodule" listing to continue from that point may be one thing, but do we have a sensible way in "git submodule add" to allow the user to recover from this condition? That is, "git add" is a right way to tell the core level that there is a gitlink, but as Yaroslav correctly observed in the early part of his message, having that gitlink alone is not good enough for the world view of "git submodule" that sits at higher-layer. And the usual way to tell the submodule layer that there is a submodule is with "git submodule add", but

	$ git init top
        $ cd top
        $ git commit --allow-empty -m 'initial in top'
        $ git init sub
        $ git -C sub commit --allow-empty -m 'initial in sub'

        $ git add sub
	$ git submodule
        fatal: no submodule mapping found in .gitmodules for path 'sub'

	$ git submodule add ./sub sub
        'sub' already exists in the index
	$ git submodule add -f ./sub sub
        'sub' already exists in the index

I highly suspect that the user will then get stuck at this point, after trying to "submodule add" and then even attempting to force it.

I think that is a more pressing thing to address. Once we make it easier for the user to bring a half-initialized submodule properly into the world view of the submodule subsystem, we would have to worry about the reported failure case even less and you do not need to pile on workaround options to let things continue in a state that is half-broken (that is, in a state that is perfectly sane to the core layer, but is not liked by the submodule layer).