Re: [BUG] 'add -u' doesn't work from untracked subdir

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

Jeff King <peff@peff.net> writes:

> I suspect it is too late to change it due to compatibility issues. OTOH,
> I think the intent of v1.7.0 is to allow a few small breakages like
> these. You could always write an RFC patch and generate some discussion;
> I'm not 100% sure that there are enough people that agree with us to
> change the default.

The intent of 1.7.0 is to fix usability glitches and warts that everybody
has long agreed are problematic.  People have *just started* discussing
about this---it is not remotely close to "everybody has long agreed are
problematic" criteria.  It is too late for 1.7.0.

I agree that there are parts of git that is very whole tree oriented, and
the later "usability" part that are cwd centric.  "add -u" and "grep" are
examples of the latter.

I personally find "add -u" that defaults to the current directory more
natural than always going to the root; same preference for "grep".
Besides, "add -u subdir" must add subdir relative to the cwd, without
going to the root.  Why should "add -u" sans argument behave drastically
differently?

Speaking of cwd-ness, I sometimes find ls-tree irritating, but I think
this is in "if we had known better we would have designed it differently,
but because we didn't, because many scripts already depend on the current
behaviour, and because we have an --full-name escape hatch, we are not
likely to change it, ever" category.

If "git add -u ../.." (I mean "the grand parent directory", not "an
unnamed subdirectory") did not work, it would be unexcusable and we would
want to devise an migration path, but otherwise I do not think it is such
a big deal.  I would say the commands that are used to incrementally build
towards the next commit should be friendly to the practice of limiting the
scope of the work by chdir, i.e. they should be cwd centric.  On the other
hand, the commands that are used to review the next commit as a whole,
e.g. diff and patch, should be whole-tree oriented.

Oh, "git grep -e foo ../..", however, does not seem to work.  That might be
something people may want to tackle.