The following patches try to provide an add.patch configuration variable
while keeping out of the way of other commands. To do so, an environment
variable counts how often git was recursively invoked. The variable is
then only considered in the first recursion.
To ensure other commands work as expected also when add.patch is set, I
added a test exemplifying the case with mergetool. To confirm the same
for other commands, I also reran all tests with an activated add.patch,
all direct invocations of git-add in the tests augmented with
--no-patch. You can reproduce this by running the following commands
from the root of the git source code repository.
sed -i '/add\.patch/,/}/ {
# pretend add.patch to always be active
s/\(patch_interactive = \).*;/\11;/
}' builtin/add.c
find t -type f -exec sed -i ' # in all tests
/(use\|forget\|hint/! { # exclude help texts
# replace git add invocations, also when options are passed to git,
# but not subcommands named add.
s/git\( -[^ ]\+ [^ ]\+\| --[^ ]\+=[^ ]\+\)* add/& --no-patch/g
}
/patch mode can be activated per option/ {
# find add.patched test now invalid and deactivate
s/\(test_expect_\)success/\1failure/
}
' '{}' +
I am unsure whether I placed all the code into the correct locations, so
comments are much appreciated, as well as opinions about the concept of
a recursion counter in general.
Regards,
XZS.
XZS (2):
count recursion depth
add a add.patch config variable
Documentation/config.txt | 6 ++++++
Documentation/git-add.txt | 3 +++
builtin/add.c | 3 +++
cache.h | 1 +
contrib/completion/git-completion.bash | 1 +
git.c | 18 ++++++++++++++++++
t/t0001-init.sh | 1 +
t/t0120-recursion-depth.sh | 17 +++++++++++++++++
t/t3701-add-interactive.sh | 27 +++++++++++++++++++++++++++
9 files changed, 77 insertions(+)
create mode 100755 t/t0120-recursion-depth.sh
--
2.8.0
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html