Re: "git add -u" broken in git 1.7.4?
- From
Matthieu Moy <matthieu.moy@grenoble-inp.fr>
- Date
- Feb 7, 2011, 06:48 UTC
- Message-ID
- <vpqbp2ojq5x.fsf@bauges.imag.fr>
- In-Reply-To
- <20110207055314.GA5511@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 10 quoted lines
> On Sun, Feb 06, 2011 at 09:50:37PM -0800, Junio C Hamano wrote: > >> As it takes pathspecs (think "git add -u this-file"), it fundamentally >> shouldn't be tree-wide. I think the original implementation didn't take >> pathspecs and was mistakenly done as tree-wide operation, but I think it >> was fixed rather quickly. > > Is "git add -p" broken, then? It takes pathspecs relative to the current > directory, but "git add -p" without arguments operates from the root, > not from the current subdirectory.
It's not just "git add -p". Take "git log", "git status", "git commit", "git diff" ... well, most Git commands taking pathspecs optionally:
git foo => tree-wide git foo . => the . acts as a path limiter
and this is the right thing to do. Making "git foo" equivalent to "git foo ." makes it hard to recover the tree-wide behavior from a subdirectory (git foo ../../../).
-- Matthieu Moy http://www-verimag.imag.fr/~moy/