Re: 'git add' option to non-interactively stage working tree changes

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 7, 2011, 20:44 UTC
Message-ID: <7vfwt45tqv.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTi=iwOGv3PzrRcVGDwwoTXmJ4CuC11vuYsjn4xxV@mail.gmail.com>

Hrvoje Nikšić <hniksic@gmail.com> writes:

> Thanks for the tip. I'll note that this is not exactly easy to
> discover, though, and it's quite some typing. Since git add -p and git
> add -i seem capable of determining the root themselves, maybe there
> should be a way to do the same for -u? Or even make it the default?

The general design principle when talking about an operation to build towards the next commit is to limit the operation to the current working directory when working from a subdirectory, so I would have to say that what -p and -i do is wrong, but this is already a very well established behaviour and there is no way to change the default (the same thing can be said for what -u does).

I think it might be Ok to introduce a --full-tree option to "git add" (and "git grep"), though. But introduction of corresponding configuration variable to flip the default needs to be done carefully in steps across major version boundaries as usual (i.e. first introduce --no-full-tree, wait for 9 to 12 months to make sure scripts are updated, then start honoring add.fullTree and grep.fullTree configuration variables).