Re: "git add -u" broken in git 1.7.4?

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> 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.

I would say so; "add -p" was an ill-executed afterthought.  The codepath
was originally meant to be used from "-i" as the top-level interface that
was a fully interactive way to prepare for the next commit, which is an
operation that is inherently full-tree.

There are two schools of thought in previous threads discussing full-tree
vs current-directory-relative.  I think each side has merits.

If we defaulted to the current directory (i.e. "git grep"), that would
feel more natural as it is more consistent with how tools that are not git
aware (e.g. "GNU grep" run in the same directory) behave.  A downside is
when you are somewhere deep in a working tree, you have to know how deep
you are and repeat "../" that many times, i.e. "git grep pattern ../../"

If we defaulted to the root-level (i.e. "git diff"), you do not have that
downside (iow, "git diff" run from a deep directory is a full tree
operation), and you can limit the scope to the current directory by a
single dot, i.e. "git diff .".  A huge downside is that this may feel
awkward for new people who do not yet breath git [*1*], as no other git
aware tool would behave like this, limiting its scope to some directory
that is higher above.

In the past, I have took the third position, saying that tools that
semantically needs to be full-tree should be full-tree (i.e. ones that
make or format commits), and others should be relative to the current
directory (i.e. ones that are used to inspect your progress, such as
grep), but that is not a very understandable guideline that people can
easily follow.  If we have to choose between the two and make things
consistent, my personal preference is to make everything relative to the
current working directory.

I actually do not mind too much myself if all commands that can take
pathspecs consistently defaulted to "full-tree" pathspec given no
pathspec.  But if we were to go that route, everybody should join their
voice to defend that decision when outside people say "in 1.8.0 'git grep'
run from a subdirectory shows matches from all the irrelevant parts of the
tree; with all the cruft its output is unreadable". I won't be the sole
champion of such a behaviour when I do not fully believe in it.


[Footnote]

*1* In the case of "git diff", this is largely mitigated as its output is
always relative to the root of the working tree, but other tools may not
have that luxury.