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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 5, 2009, 07:02 UTC
Message-ID: <7v8wgt98ms.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20090905061804.GB29863@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

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