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

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

[Hrvoje Nikšić]

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.

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

[Andreas Schwab]

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

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

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

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Hrvoje Nikšić]

On Fri, Jan 7, 2011 at 8:52 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Hrvoje Nikšić <hniksic@gmail.com> writes:
>
>> 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.
>
> You can always use "$(git rev-parse --show-cdup)." as the root.

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?

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

[Junio C Hamano]

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

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

[Jakub Narebski]

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

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

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
-- 
Jakub Narebski
Poland
ShadeHawk on #git