Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)
- From
Thomas Rast <trast@inf.ethz.ch>
- Date
- Apr 17, 2013, 15:56 UTC
- Message-ID
- <87wqs1xi9h.fsf@hexa.v.cablecom.net>
- In-Reply-To
- <7vd2ttgoyr.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 13 quoted lines
> 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.
Show 11 quoted lines
>> 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