Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

[Thomas Rast <trast@inf.ethz.ch>]

Junio C Hamano <gitster@pobox.com> writes:

> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> The warning triggers in some cases where it shouldn't, relating to
>> submodules:
>>
>>   $ git submodule add gitosis@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