Stefan Beller <sbeller@xxxxxxxxxx> 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...
--
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