From: Thomas Rast Date: Wed, 17 Apr 2013 15:56:58 GMT Subject: Re: What's cooking in git.git (Apr 2013, #05; Mon, 15) Message-ID: <87wqs1xi9h.fsf@hexa.v.cablecom.net> In-Reply-To: <7vd2ttgoyr.fsf@alter.siamese.dyndns.org> Junio C Hamano writes: > Thomas Rast 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 ...' 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 ...' 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