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

> Stefan Beller <sbeller@google.com> writes:
>
>> 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...