Re: [PATCH] submodule helper: accept '.' for repositories with no submodules

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 22, 2016, 22:04 UTC
Message-ID: <xmqqpoumf9uy.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kYNQ46Yett8xwtPL8Mi1TkitB1kuWbQDsR6bg-5dxckNA@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 5 quoted lines

> I was under the impression that we do not want to have this bugfix
> (at least long term) and then I tried to come up with an idea,
> which is both:
> * correct in this case
> * and catches the git submodule init -- 'COPYIN*' case as failure

Satisfying both has to be impossible, I am afraid, so coming up with an idea to do so may be futile.

If "git submodule $subcmd -- 'COPYIN*'" must fail (which I think is a good property to have), then "git submodule $subcmd -- ." must fail if there is no submodule in the repository, I would think, if we want to be consistent. Both are complaining not just because there is no path that match the given pathspec, but because there is no submodule that match the given pathspec.

That is why I said I was in favour of giving some _other_ way, other than "this is guaranteed to match some submodule" pathspec (which fundamentally does not exist, because there are projects that do not have any submodule in them), as a suggestion for "deinit all" safety.

A slight tangent.

We have --error-unmatch in ls-files to detect pathspec that did not hit anything, and our Porcelain commands treat a pathspec that does not hit anything as an error, but there probably need to be "--unmatch-ok" option? I.e.

	$ git add 'A*'
        fatal: pathspec 'A*' did not match any files
        $ git add --unmatch-ok 'A*'
        ... nothing is added but we do not get an error ...

Then the interaction may go like this:

	$ git submodule deinit
        You need to limit submodules to deinit with some pathspec
        $ git submodule deinit .
        fatal: pathspec '.' did not match any submodule
        $ git submodule deinit --unmatch-ok .
        ... nothing deinited but we do not get an error ...

For this particular one,

	$ git submodule deinit --force

may be also OK, but there may be _other_ conditions that you may allow overriding in "deinit" operation (e.g. we may refuse to deinit when there are unsaved/unuploaded changes, and allow --force to override it), so...