On Tue, Mar 22, 2016 at 3:04 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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... That sounds better thought than my thinking. So for now I would send the performance regressing flip of IS_GITLINK and match_pathspec targeting 2.7 and then add a --unmatch-ok switch for 2.8 and later? -- 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