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

Is there a way to non-interactively instruct git to stage all changes in the working tree, specifically those that would be detected by "git add -p" or "git commit -a"?

One can use "git add" for this purpose, but it is necessary to specify the root, and with the unpleasant side effect of adding untracked files. "git add -u" avoids the file addition, but root still has to be spelled out. "git add -p" does exactly the right thing, but requires interaction. I would like an automated --yes-to-all version of "git add -p".

Specifying the root may seem innocuous, but it is inconsistent with "git diff" and "git commit [-a]", which don't care where in the tree you are.

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

You can always use "$(git rev-parse --show-cdup)." as the root.

Andreas.

On Fri, Jan 7, 2011 at 8:52 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:

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?

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

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

Junio C Hamano <gitster@pobox.com> writes:

You meant --relative[1] here (instead of --no-full-tree), didn't you?

[1] Supported by diff, and in a way by git-diff-tree