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

From: Thomas Rast <[email-masked]>
Date: Wed, 17 Apr 2013 17:56:58 +0200

Junio C Hamano <[email-masked]> writes:

> Thomas Rast <[email-masked]> writes:
>
>> The warning triggers in some cases where it shouldn't, relating to
>> submodules:
>>
>>   $ git submodule add [email-masked]: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