Junio C Hamano <gits...@pobox.com> writes:
> Thomas Rast <tr...@inf.ethz.ch> writes:
>
>> The warning triggers in some cases where it shouldn't, relating to
>> submodules:
>>
>> $ git submodule add gito...@git.csa.inf.ethz.ch:domjudge.git domjudge
>> Adding existing repo at 'domjudge' to the index
>> warning: In Git 2.0, 'git add <pathspec>...' will also update
>> the index for paths removed from the working tree that match
>> the given pathspec. If you want to 'add' only changed
>> or newly created paths, say 'git add --no-all <pathspec>...' instead.
>
> Good one. So "add" used internally there needs to say --no-add?
I think the logic in git-add needs to learn about submodules. The same
warning later trigger when you later say 'git add submoduledir', even
though that obviously doesn't walk inside the submodule.
>> It also seems to hint that the problem is with giving a 'pathspec', but
>> in fact in the case of a "proper" pathspec (that isn't an existing path)
>> it does *not* trigger, even though it probably should:
>
> We have seen users who explicitly say:
>
> git add dir
>
> after removing dir/del and adding dir/ins got surprised that we do
> not notice removal of dir/del without "add -A". And it is fairly
> straight-forward to check and warn for such a case.
I can see that problem, but along the same lines, why shouldn't I have
an expectation that when I say 'git add "*.py"' it removes stuff that I
have removed? That's what I tried to show with the f?o example.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
