git-commit-vandalism/t/t3701-add-interactive.sh

643 lines
14 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='add -i basic tests'
. ./test-lib.sh
. "$TEST_DIRECTORY"/lib-terminal.sh
if ! test_have_prereq PERL
then
skip_all='skipping add -i tests, perl not available'
test_done
fi
diff_cmp () {
for x
do
sed -e '/^index/s/[0-9a-f]*[1-9a-f][0-9a-f]*\.\./1234567../' \
-e '/^index/s/\.\.[0-9a-f]*[1-9a-f][0-9a-f]*/..9abcdef/' \
-e '/^index/s/ 00*\.\./ 0000000../' \
-e '/^index/s/\.\.00*$/..0000000/' \
-e '/^index/s/\.\.00* /..0000000 /' \
"$x" >"$x.filtered"
done
test_cmp "$1.filtered" "$2.filtered"
}
test_expect_success 'setup (initial)' '
echo content >file &&
git add file &&
echo more >>file &&
echo lines >>file
'
test_expect_success 'status works (initial)' '
git add -i </dev/null >output &&
grep "+1/-0 *+2/-0 file" output
'
test_expect_success 'setup expected' '
cat >expected <<-\EOF
new file mode 100644
index 0000000..d95f3ad
--- /dev/null
+++ b/file
@@ -0,0 +1 @@
+content
EOF
'
test_expect_success 'diff works (initial)' '
test_write_lines d 1 | git add -i >output &&
sed -ne "/new file/,/content/p" <output >diff &&
diff_cmp expected diff
'
test_expect_success 'revert works (initial)' '
git add file &&
test_write_lines r 1 | git add -i &&
git ls-files >output &&
! grep . output
'
test_expect_success 'setup (commit)' '
echo baseline >file &&
git add file &&
git commit -m commit &&
echo content >>file &&
git add file &&
echo more >>file &&
echo lines >>file
'
test_expect_success 'status works (commit)' '
git add -i </dev/null >output &&
grep "+1/-0 *+2/-0 file" output
'
test_expect_success 'setup expected' '
cat >expected <<-\EOF
index 180b47c..b6f2c08 100644
--- a/file
+++ b/file
@@ -1 +1,2 @@
baseline
+content
EOF
'
test_expect_success 'diff works (commit)' '
test_write_lines d 1 | git add -i >output &&
sed -ne "/^index/,/content/p" <output >diff &&
diff_cmp expected diff
'
test_expect_success 'revert works (commit)' '
git add file &&
test_write_lines r 1 | git add -i &&
git add -i </dev/null >output &&
grep "unchanged *+3/-0 file" output
'
test_expect_success 'setup expected' '
cat >expected <<-\EOF
EOF
'
test_expect_success 'dummy edit works' '
test_set_editor : &&
test_write_lines e a | git add -p &&
git diff > diff &&
diff_cmp expected diff
'
test_expect_success 'setup patch' '
cat >patch <<-\EOF
@@ -1,1 +1,4 @@
this
+patch
-does not
apply
EOF
'
test_expect_success 'setup fake editor' '
write_script "fake_editor.sh" <<-\EOF &&
mv -f "$1" oldpatch &&
mv -f patch "$1"
EOF
test_set_editor "$(pwd)/fake_editor.sh"
'
test_expect_success 'bad edit rejected' '
git reset &&
test_write_lines e n d | git add -p >output &&
grep "hunk does not apply" output
'
test_expect_success 'setup patch' '
cat >patch <<-\EOF
this patch
is garbage
EOF
'
test_expect_success 'garbage edit rejected' '
git reset &&
test_write_lines e n d | git add -p >output &&
grep "hunk does not apply" output
'
test_expect_success 'setup patch' '
cat >patch <<-\EOF
@@ -1,0 +1,0 @@
baseline
+content
+newcontent
+lines
EOF
'
test_expect_success 'setup expected' '
cat >expected <<-\EOF
diff --git a/file b/file
index b5dd6c9..f910ae9 100644
--- a/file
+++ b/file
@@ -1,4 +1,4 @@
baseline
content
-newcontent
+more
lines
EOF
'
test_expect_success 'real edit works' '
test_write_lines e n d | git add -p &&
git diff >output &&
diff_cmp expected output
'
test_expect_success 'setup file' '
test_write_lines a "" b "" c >file &&
git add file &&
test_write_lines a "" d "" c >file
'
test_expect_success 'setup patch' '
SP=" " &&
NULL="" &&
cat >patch <<-EOF
@@ -1,4 +1,4 @@
a
$NULL
-b
+f
$SP
c
EOF
'
test_expect_success 'setup expected' '
cat >expected <<-EOF
diff --git a/file b/file
index b5dd6c9..f910ae9 100644
--- a/file
+++ b/file
@@ -1,5 +1,5 @@
a
$SP
-f
+d
$SP
c
EOF
'
test_expect_success 'edit can strip spaces from empty context lines' '
test_write_lines e n q | git add -p 2>error &&
test_must_be_empty error &&
git diff >output &&
diff_cmp expected output
'
test_expect_success 'skip files similarly as commit -a' '
git reset &&
echo file >.gitignore &&
echo changed >file &&
echo y | git add -p file &&
git diff >output &&
git reset &&
git commit -am commit &&
git diff >expected &&
diff_cmp expected output &&
git reset --hard HEAD^
'
rm -f .gitignore
test_expect_success FILEMODE 'patch does not affect mode' '
git reset --hard &&
echo content >>file &&
chmod +x file &&
printf "n\\ny\\n" | git add -p &&
git show :file | grep content &&
git diff file | grep "new mode"
'
test_expect_success FILEMODE 'stage mode but not hunk' '
git reset --hard &&
echo content >>file &&
chmod +x file &&
printf "y\\nn\\n" | git add -p &&
git diff --cached file | grep "new mode" &&
git diff file | grep "+content"
'
test_expect_success FILEMODE 'stage mode and hunk' '
git reset --hard &&
echo content >>file &&
chmod +x file &&
printf "y\\ny\\n" | git add -p &&
git diff --cached file | grep "new mode" &&
git diff --cached file | grep "+content" &&
test -z "$(git diff file)"
'
# end of tests disabled when filemode is not usable
test_expect_success 'setup again' '
git reset --hard &&
test_chmod +x file &&
echo content >>file
'
# Write the patch file with a new line at the top and bottom
test_expect_success 'setup patch' '
cat >patch <<-\EOF
index 180b47c..b6f2c08 100644
--- a/file
+++ b/file
@@ -1,2 +1,4 @@
+firstline
baseline
content
+lastline
\ No newline at end of file
EOF
'
# Expected output, diff is similar to the patch but w/ diff at the top
test_expect_success 'setup expected' '
echo diff --git a/file b/file >expected &&
cat patch |sed "/^index/s/ 100644/ 100755/" >>expected &&
cat >expected-output <<-\EOF
--- a/file
+++ b/file
@@ -1,2 +1,4 @@
+firstline
baseline
content
+lastline
\ No newline at end of file
@@ -1,2 +1,3 @@
+firstline
baseline
content
@@ -1,2 +2,3 @@
baseline
content
+lastline
\ No newline at end of file
EOF
'
# Test splitting the first patch, then adding both
test_expect_success C_LOCALE_OUTPUT 'add first line works' '
git commit -am "clear local changes" &&
git apply patch &&
printf "%s\n" s y y | git add -p file 2>error |
sed -n -e "s/^Stage this hunk[^@]*\(@@ .*\)/\1/" \
-e "/^[-+@ \\\\]"/p >output &&
test_must_be_empty error &&
git diff --cached >diff &&
diff_cmp expected diff &&
test_cmp expected-output output
'
test_expect_success 'setup expected' '
cat >expected <<-\EOF
diff --git a/non-empty b/non-empty
deleted file mode 100644
index d95f3ad..0000000
--- a/non-empty
+++ /dev/null
@@ -1 +0,0 @@
-content
EOF
'
test_expect_success 'deleting a non-empty file' '
git reset --hard &&
echo content >non-empty &&
git add non-empty &&
git commit -m non-empty &&
rm non-empty &&
echo y | git add -p non-empty &&
git diff --cached >diff &&
diff_cmp expected diff
'
test_expect_success 'setup expected' '
cat >expected <<-\EOF
diff --git a/empty b/empty
deleted file mode 100644
index e69de29..0000000
EOF
'
test_expect_success 'deleting an empty file' '
git reset --hard &&
> empty &&
git add empty &&
git commit -m empty &&
rm empty &&
echo y | git add -p empty &&
git diff --cached >diff &&
diff_cmp expected diff
'
test_expect_success 'split hunk setup' '
git reset --hard &&
test_write_lines 10 20 30 40 50 60 >test &&
git add test &&
test_tick &&
git commit -m test &&
test_write_lines 10 15 20 21 22 23 24 30 40 50 60 >test
'
test_expect_success 'split hunk "add -p (edit)"' '
# Split, say Edit and do nothing. Then:
#
# 1. Broken version results in a patch that does not apply and
# only takes [y/n] (edit again) so the first q is discarded
# and then n attempts to discard the edit. Repeat q enough
# times to get out.
#
# 2. Correct version applies the (not)edited version, and asks
# about the next hunk, against which we say q and program
# exits.
printf "%s\n" s e q n q q |
EDITOR=: git add -p &&
git diff >actual &&
! grep "^+15" actual
'
test_expect_failure 'split hunk "add -p (no, yes, edit)"' '
test_write_lines 5 10 20 21 30 31 40 50 60 >test &&
git reset &&
# test sequence is s(plit), n(o), y(es), e(dit)
# q n q q is there to make sure we exit at the end.
printf "%s\n" s n y e q n q q |
EDITOR=: git add -p 2>error &&
test_must_be_empty error &&
git diff >actual &&
! grep "^+31" actual
'
test_expect_success 'patch mode ignores unmerged entries' '
git reset --hard &&
test_commit conflict &&
test_commit non-conflict &&
git checkout -b side &&
test_commit side conflict.t &&
git checkout master &&
test_commit master conflict.t &&
test_must_fail git merge side &&
echo changed >non-conflict.t &&
echo y | git add -p >output &&
! grep a/conflict.t output &&
cat >expected <<-\EOF &&
* Unmerged path conflict.t
diff --git a/non-conflict.t b/non-conflict.t
index f766221..5ea2ed4 100644
--- a/non-conflict.t
+++ b/non-conflict.t
@@ -1 +1 @@
-non-conflict
+changed
EOF
git diff --cached >diff &&
diff_cmp expected diff
'
test_expect_success TTY 'diffs can be colorized' '
color_parse_mem: allow empty color spec Prior to c2f41bf52 (color.c: fix color_parse_mem() with value_len == 0, 2017-01-19), the empty string was interpreted as a color "reset". This was an accidental outcome, and that commit turned it into an error. However, scripts may pass the empty string as a default value to "git config --get-color" to disable color when the value is not defined. The git-add--interactive script does this. As a result, the script is unusable since c2f41bf52 unless you have color.diff.plain defined (if it is defined, then we don't parse the empty default at all). Our test scripts didn't notice the recent breakage because they run without a terminal, and thus without color. They never hit this code path at all. And nobody noticed the original buggy "reset" behavior, because it was effectively a noop. Let's fix the code to have an empty color name produce an empty sequence of color codes. The tests need a few fixups: - we'll add a new test in t4026 to cover this case. But note that we need to tweak the color() helper. While we're there, let's factor out the literal ANSI ESC character. Otherwise it makes the diff quite hard to read. - we'll add a basic sanity-check in t4026 that "git add -p" works at all when color is enabled. That would have caught this bug, as well as any others that are specific to the color code paths. - 73c727d69 (log --graph: customize the graph lines with config log.graphColors, 2017-01-19) added a test to t4202 that checks some "invalid" graph color config. Since ",, blue" before yielded only "blue" as valid, and now yields "empty, empty, blue", we don't match the expected output. One way to fix this would be to change the expectation to the empty color strings. But that makes the test much less interesting, since we show only two graph lines, both of which would be colorless. Since the empty-string case is now covered by t4026, let's remove them entirely here. They're just in the way of the primary thing the test is supposed to be checking. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-01 01:21:29 +01:00
git reset --hard &&
echo content >test &&
printf y | test_terminal git add -p >output 2>&1 &&
color_parse_mem: allow empty color spec Prior to c2f41bf52 (color.c: fix color_parse_mem() with value_len == 0, 2017-01-19), the empty string was interpreted as a color "reset". This was an accidental outcome, and that commit turned it into an error. However, scripts may pass the empty string as a default value to "git config --get-color" to disable color when the value is not defined. The git-add--interactive script does this. As a result, the script is unusable since c2f41bf52 unless you have color.diff.plain defined (if it is defined, then we don't parse the empty default at all). Our test scripts didn't notice the recent breakage because they run without a terminal, and thus without color. They never hit this code path at all. And nobody noticed the original buggy "reset" behavior, because it was effectively a noop. Let's fix the code to have an empty color name produce an empty sequence of color codes. The tests need a few fixups: - we'll add a new test in t4026 to cover this case. But note that we need to tweak the color() helper. While we're there, let's factor out the literal ANSI ESC character. Otherwise it makes the diff quite hard to read. - we'll add a basic sanity-check in t4026 that "git add -p" works at all when color is enabled. That would have caught this bug, as well as any others that are specific to the color code paths. - 73c727d69 (log --graph: customize the graph lines with config log.graphColors, 2017-01-19) added a test to t4202 that checks some "invalid" graph color config. Since ",, blue" before yielded only "blue" as valid, and now yields "empty, empty, blue", we don't match the expected output. One way to fix this would be to change the expectation to the empty color strings. But that makes the test much less interesting, since we show only two graph lines, both of which would be colorless. Since the empty-string case is now covered by t4026, let's remove them entirely here. They're just in the way of the primary thing the test is supposed to be checking. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-01 01:21:29 +01:00
# We do not want to depend on the exact coloring scheme
# git uses for diffs, so just check that we saw some kind of color.
grep "$(printf "\\033")" output
'
test_expect_success TTY 'diffFilter filters diff' '
git reset --hard &&
echo content >test &&
test_config interactive.diffFilter "sed s/^/foo:/" &&
printf y | test_terminal git add -p >output 2>&1 &&
# avoid depending on the exact coloring or content of the prompts,
# and just make sure we saw our diff prefixed
grep foo:.*content output
'
test_expect_success TTY 'detect bogus diffFilter output' '
git reset --hard &&
echo content >test &&
test_config interactive.diffFilter "echo too-short" &&
printf y | test_must_fail test_terminal git add -p
'
test_expect_success 'patch-mode via -i prompts for files' '
git reset --hard &&
echo one >file &&
echo two >test &&
git add -i <<-\EOF &&
patch
test
y
quit
EOF
echo test >expect &&
git diff --cached --name-only >actual &&
diff_cmp expect actual
'
add--interactive: do not expand pathspecs with ls-files When we want to get the list of modified files, we first expand any user-provided pathspecs with "ls-files", and then feed the resulting list of paths as arguments to "diff-index" and "diff-files". If your pathspec expands into a large number of paths, you may run into one of two problems: 1. The OS may complain about the size of the argument list, and refuse to run. For example: $ (ulimit -s 128 && git add -p drivers) Can't exec "git": Argument list too long at .../git-add--interactive line 177. Died at .../git-add--interactive line 177. That's on the linux.git repository, which has about 20K files in the "drivers" directory (none of them modified in this case). The "ulimit -s" trick is necessary to show the problem on Linux even for such a gigantic set of paths. Other operating systems have much smaller limits (e.g., a real-world case was seen with only 5K files on OS X). 2. Even when it does work, it's really slow. The pathspec code is not optimized for huge numbers of paths. Here's the same case without the ulimit: $ time git add -p drivers No changes. real 0m16.559s user 0m53.140s sys 0m0.220s We can improve this by skipping "ls-files" completely, and just feeding the original pathspecs to the diff commands. This solution was discussed in 2010: http://public-inbox.org/git/20100105041438.GB12574@coredump.intra.peff.net/ but at the time the diff code's pathspecs were more primitive than those used by ls-files (e.g., they did not support globs). Making the change would have caused a user-visible regression, so we didn't. Since then, the pathspec code has been unified, and the diff commands natively understand pathspecs like '*.c'. This patch implements that solution. That skips the argument-list limits, and the result runs much faster: $ time git add -p drivers No changes. real 0m0.149s user 0m0.116s sys 0m0.080s There are two new tests. The first just exercises the globbing behavior to confirm that we are not causing a regression there. The second checks the actual argument behavior using GIT_TRACE. We _could_ do it with the "ulimit -s" trick, as above. But that would mean the test could only run where "ulimit -s" works. And tests of that sort are expensive, because we have to come up with enough files to actually bust the limit (we can't just shrink the "128" down infinitely, since it is also the in-program stack size). Finally, two caveats and possibilities for future work: a. This fixes one argument-list expansion, but there may be others. In fact, it's very likely that if you run "git add -i" and select a large number of modified files that the script would try to feed them all to a single git command. In practice this is probably fine. The real issue here is that the argument list was growing with the _total_ number of files, not the number of modified or selected files. b. If the repository contains filenames with literal wildcard characters (e.g., "foo*"), the original code expanded them via "ls-files" and then fed those wildcard names to "diff-index", which would have treated them as wildcards. This was a bug, which is now fixed (though unless you really go through some contortions with ":(literal)", it's likely that your original pathspec would match whatever the accidentally-expanded wildcard would anyway). So this takes us one step closer to working correctly with files whose names contain wildcard characters, but it's likely that others remain (e.g., if "git add -i" feeds the selected paths to "git add"). Reported-by: Wincent Colaiuta <win@wincent.com> Reported-by: Mislav Marohnić <mislav.marohnic@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-14 17:30:24 +01:00
test_expect_success 'add -p handles globs' '
git reset --hard &&
mkdir -p subdir &&
echo base >one.c &&
echo base >subdir/two.c &&
git add "*.c" &&
git commit -m base &&
echo change >one.c &&
echo change >subdir/two.c &&
git add -p "*.c" <<-\EOF &&
y
y
EOF
cat >expect <<-\EOF &&
one.c
subdir/two.c
EOF
git diff --cached --name-only >actual &&
test_cmp expect actual
'
pathspec: honor `PATHSPEC_PREFIX_ORIGIN` with empty prefix Previous to commit 5d8f084a5 (pathspec: simpler logic to prefix original pathspec elements, 2017-01-04), we were always using the computed `match` variable to perform pathspec matching whenever `PATHSPEC_PREFIX_ORIGIN` is set. This is for example useful when passing the parsed pathspecs to other commands, as the computed `match` may contain a pathspec relative to the repository root. The commit changed this logic to only do so when we do have an actual prefix and when literal pathspecs are deactivated. But this change may actually break some commands which expect passed pathspecs to be relative to the repository root. One such case is `git add --patch`, which now fails when using relative paths from a subdirectory. For example if executing "git add -p ../foo.c" in a subdirectory, the `git-add--interactive` command will directly pass "../foo.c" to `git-ls-files`. As ls-files is executed at the repository's root, the command will notice that "../foo.c" is outside the repository and fail. Fix the issue by again using the computed `match` variable when `PATHSPEC_PREFIX_ORIGIN` is set and global literal pathspecs are deactivated. Note that in contrast to previous behavior, we will now always call `prefix_magic` regardless of whether a prefix is actually set. But this is the right thing to do: when the `match` variable has been resolved to the repository's root, it will be set to an empty string. When passing the empty string directly to other commands, it will result in a warning regarding deprecated empty pathspecs. By always adding the prefix magic, we will end up with at least the string ":(prefix:0)" and thus avoid the warning. Signed-off-by: Patrick Steinhardt <ps@pks.im> Acked-by: Brandon Williams <bmwill@google.com> Reviewed-by: Duy Nguyen <pclouds@gmail.com>
2017-04-04 11:16:56 +02:00
test_expect_success 'add -p handles relative paths' '
git reset --hard &&
echo base >relpath.c &&
git add "*.c" &&
git commit -m relpath &&
echo change >relpath.c &&
mkdir -p subdir &&
git -C subdir add -p .. 2>error <<-\EOF &&
y
EOF
test_must_be_empty error &&
cat >expect <<-\EOF &&
relpath.c
EOF
git diff --cached --name-only >actual &&
test_cmp expect actual
'
add--interactive: do not expand pathspecs with ls-files When we want to get the list of modified files, we first expand any user-provided pathspecs with "ls-files", and then feed the resulting list of paths as arguments to "diff-index" and "diff-files". If your pathspec expands into a large number of paths, you may run into one of two problems: 1. The OS may complain about the size of the argument list, and refuse to run. For example: $ (ulimit -s 128 && git add -p drivers) Can't exec "git": Argument list too long at .../git-add--interactive line 177. Died at .../git-add--interactive line 177. That's on the linux.git repository, which has about 20K files in the "drivers" directory (none of them modified in this case). The "ulimit -s" trick is necessary to show the problem on Linux even for such a gigantic set of paths. Other operating systems have much smaller limits (e.g., a real-world case was seen with only 5K files on OS X). 2. Even when it does work, it's really slow. The pathspec code is not optimized for huge numbers of paths. Here's the same case without the ulimit: $ time git add -p drivers No changes. real 0m16.559s user 0m53.140s sys 0m0.220s We can improve this by skipping "ls-files" completely, and just feeding the original pathspecs to the diff commands. This solution was discussed in 2010: http://public-inbox.org/git/20100105041438.GB12574@coredump.intra.peff.net/ but at the time the diff code's pathspecs were more primitive than those used by ls-files (e.g., they did not support globs). Making the change would have caused a user-visible regression, so we didn't. Since then, the pathspec code has been unified, and the diff commands natively understand pathspecs like '*.c'. This patch implements that solution. That skips the argument-list limits, and the result runs much faster: $ time git add -p drivers No changes. real 0m0.149s user 0m0.116s sys 0m0.080s There are two new tests. The first just exercises the globbing behavior to confirm that we are not causing a regression there. The second checks the actual argument behavior using GIT_TRACE. We _could_ do it with the "ulimit -s" trick, as above. But that would mean the test could only run where "ulimit -s" works. And tests of that sort are expensive, because we have to come up with enough files to actually bust the limit (we can't just shrink the "128" down infinitely, since it is also the in-program stack size). Finally, two caveats and possibilities for future work: a. This fixes one argument-list expansion, but there may be others. In fact, it's very likely that if you run "git add -i" and select a large number of modified files that the script would try to feed them all to a single git command. In practice this is probably fine. The real issue here is that the argument list was growing with the _total_ number of files, not the number of modified or selected files. b. If the repository contains filenames with literal wildcard characters (e.g., "foo*"), the original code expanded them via "ls-files" and then fed those wildcard names to "diff-index", which would have treated them as wildcards. This was a bug, which is now fixed (though unless you really go through some contortions with ":(literal)", it's likely that your original pathspec would match whatever the accidentally-expanded wildcard would anyway). So this takes us one step closer to working correctly with files whose names contain wildcard characters, but it's likely that others remain (e.g., if "git add -i" feeds the selected paths to "git add"). Reported-by: Wincent Colaiuta <win@wincent.com> Reported-by: Mislav Marohnić <mislav.marohnic@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-14 17:30:24 +01:00
test_expect_success 'add -p does not expand argument lists' '
git reset --hard &&
echo content >not-changed &&
git add not-changed &&
git commit -m "add not-changed file" &&
echo change >file &&
GIT_TRACE=$(pwd)/trace.out git add -p . <<-\EOF &&
y
EOF
# we know that "file" must be mentioned since we actually
# update it, but we want to be sure that our "." pathspec
# was not expanded into the argument list of any command.
# So look only for "not-changed".
! grep -E "^trace: (built-in|exec|run_command): .*not-changed" trace.out
add--interactive: do not expand pathspecs with ls-files When we want to get the list of modified files, we first expand any user-provided pathspecs with "ls-files", and then feed the resulting list of paths as arguments to "diff-index" and "diff-files". If your pathspec expands into a large number of paths, you may run into one of two problems: 1. The OS may complain about the size of the argument list, and refuse to run. For example: $ (ulimit -s 128 && git add -p drivers) Can't exec "git": Argument list too long at .../git-add--interactive line 177. Died at .../git-add--interactive line 177. That's on the linux.git repository, which has about 20K files in the "drivers" directory (none of them modified in this case). The "ulimit -s" trick is necessary to show the problem on Linux even for such a gigantic set of paths. Other operating systems have much smaller limits (e.g., a real-world case was seen with only 5K files on OS X). 2. Even when it does work, it's really slow. The pathspec code is not optimized for huge numbers of paths. Here's the same case without the ulimit: $ time git add -p drivers No changes. real 0m16.559s user 0m53.140s sys 0m0.220s We can improve this by skipping "ls-files" completely, and just feeding the original pathspecs to the diff commands. This solution was discussed in 2010: http://public-inbox.org/git/20100105041438.GB12574@coredump.intra.peff.net/ but at the time the diff code's pathspecs were more primitive than those used by ls-files (e.g., they did not support globs). Making the change would have caused a user-visible regression, so we didn't. Since then, the pathspec code has been unified, and the diff commands natively understand pathspecs like '*.c'. This patch implements that solution. That skips the argument-list limits, and the result runs much faster: $ time git add -p drivers No changes. real 0m0.149s user 0m0.116s sys 0m0.080s There are two new tests. The first just exercises the globbing behavior to confirm that we are not causing a regression there. The second checks the actual argument behavior using GIT_TRACE. We _could_ do it with the "ulimit -s" trick, as above. But that would mean the test could only run where "ulimit -s" works. And tests of that sort are expensive, because we have to come up with enough files to actually bust the limit (we can't just shrink the "128" down infinitely, since it is also the in-program stack size). Finally, two caveats and possibilities for future work: a. This fixes one argument-list expansion, but there may be others. In fact, it's very likely that if you run "git add -i" and select a large number of modified files that the script would try to feed them all to a single git command. In practice this is probably fine. The real issue here is that the argument list was growing with the _total_ number of files, not the number of modified or selected files. b. If the repository contains filenames with literal wildcard characters (e.g., "foo*"), the original code expanded them via "ls-files" and then fed those wildcard names to "diff-index", which would have treated them as wildcards. This was a bug, which is now fixed (though unless you really go through some contortions with ":(literal)", it's likely that your original pathspec would match whatever the accidentally-expanded wildcard would anyway). So this takes us one step closer to working correctly with files whose names contain wildcard characters, but it's likely that others remain (e.g., if "git add -i" feeds the selected paths to "git add"). Reported-by: Wincent Colaiuta <win@wincent.com> Reported-by: Mislav Marohnić <mislav.marohnic@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-14 17:30:24 +01:00
'
test_expect_success 'hunk-editing handles custom comment char' '
git reset --hard &&
echo change >>file &&
test_config core.commentChar "\$" &&
echo e | GIT_EDITOR=true git add -p &&
git diff --exit-code
'
color: make "always" the same as "auto" in config It can be handy to use `--color=always` (or it's synonym `--color`) on the command-line to convince a command to produce color even if it's stdout isn't going to the terminal or a pager. What's less clear is whether it makes sense to set config variables like color.ui to `always`. For a one-shot like: git -c color.ui=always ... it's potentially useful (especially if the command doesn't directly support the `--color` option). But setting `always` in your on-disk config is much muddier, as you may be surprised when piped commands generate colors (and send them to whatever is consuming the pipe downstream). Some people have done this anyway, because: 1. The documentation for color.ui makes it sound like using `always` is a good idea, when you almost certainly want `auto`. 2. Traditionally not every command (and especially not plumbing) respected color.ui in the first place. So the confusion came up less frequently than it might have. The situation changed in 136c8c8b8f (color: check color.ui in git_default_config(), 2017-07-13), which negated point (2): now scripts using only plumbing commands (like add-interactive) are broken by this setting. That commit was fixing real issues (e.g., by making `color.ui=never` work, since `auto` is the default), so we don't want to just revert it. We could turn `always` into a noop in plumbing commands, but that creates a hard-to-explain inconsistency between the plumbing and other commands. Instead, let's just turn `always` into `auto` for all config. This does break the "one-shot" config shown above, but again, we're probably better to have simple and consistent rules than to try to special-case command-line config. There is one place where `always` should retain its meaning: on the command line, `--color=always` should continue to be the same as `--color`, overriding any isatty checks. Since the command-line parser also depends on git_config_colorbool(), we can use the existence of the "var" string to deterine whether we are serving the command-line or the config. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-03 15:46:06 +02:00
test_expect_success 'add -p works even with color.ui=always' '
git reset --hard &&
echo change >>file &&
test_config color.ui always &&
echo y | git add -p &&
echo file >expect &&
git diff --cached --name-only >actual &&
test_cmp expect actual
'
test_expect_success 'setup different kinds of dirty submodules' '
test_create_repo for-submodules &&
(
cd for-submodules &&
test_commit initial &&
test_create_repo dirty-head &&
(
cd dirty-head &&
test_commit initial
) &&
cp -R dirty-head dirty-otherwise &&
cp -R dirty-head dirty-both-ways &&
git add dirty-head &&
git add dirty-otherwise dirty-both-ways &&
git commit -m initial &&
cd dirty-head &&
test_commit updated &&
cd ../dirty-both-ways &&
test_commit updated &&
echo dirty >>initial &&
: >untracked &&
cd ../dirty-otherwise &&
echo dirty >>initial &&
: >untracked
) &&
git -C for-submodules diff-files --name-only >actual &&
cat >expected <<-\EOF &&
dirty-both-ways
dirty-head
dirty-otherwise
EOF
test_cmp expected actual &&
git -C for-submodules diff-files --name-only --ignore-submodules=dirty >actual &&
cat >expected <<-\EOF &&
dirty-both-ways
dirty-head
EOF
test_cmp expected actual
'
test_expect_success 'status ignores dirty submodules (except HEAD)' '
git -C for-submodules add -i </dev/null >output &&
grep dirty-head output &&
grep dirty-both-ways output &&
! grep dirty-otherwise output
'
test_expect_success 'set up pathological context' '
git reset --hard &&
test_write_lines a a a a a a a a a a a >a &&
git add a &&
git commit -m a &&
test_write_lines c b a a a a a a a b a a a a >a &&
test_write_lines a a a a a a a b a a a a >expected-1 &&
test_write_lines b a a a a a a a b a a a a >expected-2 &&
# check editing can cope with missing header and deleted context lines
# as well as changes to other lines
test_write_lines +b " a" >patch
'
test_expect_success 'add -p works with pathological context lines' '
git reset &&
printf "%s\n" n y |
git add -p &&
git cat-file blob :a >actual &&
test_cmp expected-1 actual
'
test_expect_success 'add -p patch editing works with pathological context lines' '
git reset &&
# n q q below is in case edit fails
printf "%s\n" e y n q q |
git add -p &&
git cat-file blob :a >actual &&
test_cmp expected-2 actual
'
test_done