git/t/t3701-add-interactive.sh

1134 lines
28 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='add -i basic tests'
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
tests: mark tests relying on the current default for `init.defaultBranch` In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 23:44:19 +00:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
. ./test-lib.sh
. "$TEST_DIRECTORY"/lib-terminal.sh
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"
}
# This function uses a trick to manipulate the interactive add to use color:
# the `want_color()` function special-cases the situation where a pager was
# spawned and Git now wants to output colored text: to detect that situation,
# the environment variable `GIT_PAGER_IN_USE` is set. However, color is
# suppressed despite that environment variable if the `TERM` variable
# indicates a dumb terminal, so we set that variable, too.
force_color () {
# The first element of $@ may be a shell function, as a result POSIX
# does not guarantee that "one-shot assignment" will not persist after
# the function call. Thus, we prevent these variables from escaping
# this function's context with this subshell.
(
GIT_PAGER_IN_USE=true &&
TERM=vt100 &&
export GIT_PAGER_IN_USE TERM &&
"$@"
)
}
test_expect_success 'warn about add.interactive.useBuiltin' '
cat >expect <<-\EOF &&
warning: the add.interactive.useBuiltin setting has been removed!
See its entry in '\''git help config'\'' for details.
No changes.
EOF
for v in = =true =false
do
git -c "add.interactive.useBuiltin$v" add -p >out 2>actual &&
test_must_be_empty out &&
test_cmp expect actual || return 1
done
'
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 'add untracked (multiple)' '
test_when_finished "git reset && rm [1-9]" &&
touch $(test_seq 9) &&
test_write_lines a "2-5 8-" | git add -i -- [1-9] &&
test_write_lines 2 3 4 5 8 9 >expected &&
git ls-files [1-9] >output &&
test_cmp expected 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 'update can stage deletions' '
>to-delete &&
git add to-delete &&
rm to-delete &&
test_write_lines u t "" | git add -i &&
git ls-files to-delete >output &&
test_must_be_empty 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 >out &&
grep "new mode" out &&
grep "+content" out &&
git diff file >out &&
test_must_be_empty out
'
# end of tests disabled when filemode is not usable
test_expect_success 'different prompts for mode change/deleted' '
git reset --hard &&
>file &&
>deleted &&
git add --chmod=+x file deleted &&
echo changed >file &&
rm deleted &&
test_write_lines n n n |
git -c core.filemode=true add -p >actual &&
sed -n "s/^\(([0-9/]*) Stage .*?\).*/\1/p" actual >actual.filtered &&
cat >expect <<-\EOF &&
(1/1) Stage deletion [y,n,q,a,d,?]?
(1/2) Stage mode change [y,n,q,a,d,j,J,g,/,?]?
(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]?
EOF
test_cmp expect actual.filtered
'
test_expect_success 'correct message when there is nothing to do' '
git reset --hard &&
git add -p 2>err &&
test_i18ngrep "No changes" err &&
printf "\\0123" >binary &&
git add binary &&
printf "\\0abc" >binary &&
git add -p 2>err &&
test_i18ngrep "Only binary files changed" err
'
test_expect_success 'setup again' '
git reset --hard &&
test_chmod +x file &&
echo content >>file &&
test_write_lines A B C D>file2 &&
git add file2
'
# 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
diff --git a/file2 b/file2
index 8422d40..35b930a 100644
--- a/file2
+++ b/file2
@@ -1,4 +1,5 @@
-A
+Z
B
+Y
C
-D
+X
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 &&
sed -e "/^index 180b47c/s/ 100644/ 100755/" \
-e /1,5/s//1,4/ \
-e /Y/d patch >>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
--- a/file2
+++ b/file2
@@ -1,4 +1,5 @@
-A
+Z
B
+Y
C
-D
+X
@@ -1,2 +1,2 @@
-A
+Z
B
@@ -2,2 +2,3 @@
B
+Y
C
@@ -3,2 +4,2 @@
C
-D
+X
EOF
'
# Test splitting the first patch, then adding both
test_expect_success 'add first line works' '
git commit -am "clear local changes" &&
git apply patch &&
test_write_lines s y y s y n y | git add -p 2>error >raw-output &&
sed -n -e "s/^([1-9]\/[1-9]) Stage this hunk[^@]*\(@@ .*\)/\1/" \
-e "/^[-+@ \\\\]"/p raw-output >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 'adding an empty file' '
git init added &&
(
cd added &&
test_commit initial &&
>empty &&
git add empty &&
test_tick &&
git commit -m empty &&
git tag added-file &&
git reset --hard HEAD^ &&
test_path_is_missing empty &&
echo y | git checkout -p added-file -- >actual &&
test_path_is_file empty &&
test_i18ngrep "Apply addition to index and worktree" actual
)
'
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 'goto hunk' '
test_when_finished "git reset" &&
tr _ " " >expect <<-EOF &&
(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]? + 1: -1,2 +1,3 +15
_ 2: -2,4 +3,8 +21
go to which hunk? @@ -1,2 +1,3 @@
_10
+15
_20
(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?_
EOF
test_write_lines s y g 1 | git add -p >actual &&
tail -n 7 <actual >actual.trimmed &&
test_cmp expect actual.trimmed
'
test_expect_success 'navigate to hunk via regex' '
test_when_finished "git reset" &&
tr _ " " >expect <<-EOF &&
(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]? @@ -1,2 +1,3 @@
_10
+15
_20
(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]?_
EOF
test_write_lines s y /1,2 | git add -p >actual &&
tail -n 5 <actual >actual.trimmed &&
test_cmp expect actual.trimmed
'
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_success '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 'split hunk with incomplete line at end' '
git reset --hard &&
printf "missing LF" >>test &&
git add test &&
test_write_lines before 10 20 30 40 50 60 70 >test &&
git grep --cached missing &&
test_write_lines s n y q | git add -p &&
test_must_fail git grep --cached missing &&
git grep before &&
test_must_fail git grep --cached before
'
test_expect_success 'edit, adding lines to the first hunk' '
test_write_lines 10 11 20 30 40 50 51 60 >test &&
git reset &&
tr _ " " >patch <<-EOF &&
@@ -1,5 +1,6 @@
_10
+11
+12
_20
+21
+22
_30
EOF
# test sequence is s(plit), e(dit), n(o)
# q n q q is there to make sure we exit at the end.
printf "%s\n" s e n q n q q |
EDITOR=./fake_editor.sh git add -p 2>error &&
test_must_be_empty error &&
git diff --cached >actual &&
grep "^+22" 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 main &&
test_commit main 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 'index is refreshed after applying patch' '
git reset --hard &&
echo content >test &&
printf y | git add -p &&
git diff-files --exit-code
'
test_expect_success '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 00:21:29 +00:00
git reset --hard &&
echo content >test &&
printf y >y &&
force_color git add -p >output 2>&1 <y &&
add--interactive.perl: specify --no-color explicitly Our color tests of "git add -p" do something a bit different from how a normal user would behave: we pretend there's a pager in use, so that Git thinks it's OK to write color to a non-tty stdout. This comes from 8539b46534 (t3701: avoid depending on the TTY prerequisite, 2019-12-06), which allows us to avoid a lot of complicated mock-tty code. However, those environment variables also make their way down to sub-processes of add--interactive, including the "diff-files" we run to generate the patches. As a result, it thinks it should output color, too. So in t3701.50, for example, the machine-readable version of the diff we get unexpectedly has color in it. We fail to parse it as a diff and think there are zero hunks. The test does still pass, though, because even with zero hunks we'll dump the diff header (and we consider those unparseable bits to be part of the header!), and so the output still has the expected color codes in it. We don't notice that the command was totally broken and failed to apply anything. And in fact we're not really testing what we think we are about the color, either. While add--interactive does correctly show the version we got from running "diff-files --color", we'd also pass the test if we had accidentally shown the machine-readable version, too, since it (erroneously) has color codes in it. One could argue that the test isn't very realistic; it's setting up this "pretend there's a pager" situation to get around the tty restrictions of the test environment. So one option would be to move back towards using a real tty. But the behavior of add--interactive really is user-visible here. If a user, for whatever reason, did run "git --paginate add --patch" (perhaps because their pager is really a filter or something), the command would totally fail to do anything useful. Since we know that we don't want color in this output, let's just make add--interactive more defensive, and say "--no-color" explicitly. It doesn't hurt anything in the common case, but it fixes this odd case and lets our test function properly again. Note that the C builtin run_add_p() already passes --no-color, so it doesn't need a similar fix. That will eventually replace this perl code anyway, but the test change here will be valuable for ensuring that. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-07 08:17:39 +00:00
git diff-files --exit-code &&
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 00:21:29 +00: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
'
add -i: verify in the tests that colors can be overridden Now that the Perl version produces the same output as the built-in version (mostly fixing bugs in the latter), let's add a regression test to verify that it stays this way. Note that we only `grep` for the colored error message instead of verifying that the entire `stderr` consists of just this one line: when running the test script using the `-x` option to trace the commands, the sub-shell in `force_color` causes those commands to be traced into `err.raw` (unless running in Bash where we set the `BASH_XTRACEFD` variable to avoid that). Also note that the color reset in the `<BLUE>+<RESET><BLUE>new<RESET>` line might look funny and unnecessary, as the corresponding `old` line does not reset the color after the diff marker only to turn the color back on right away. However, this is a (necessary) side effect of the white-space check: in `emit_line_ws_markup()`, we first emit the diff marker via `emit_line_0()` and then the rest of the line via `ws_check_emit()`. To leave them somewhat decoupled, the color has to be reset after the diff marker to allow for the rest of the line to start with another color (or inverted, in case of white-space issues). Finally, we have to simulate hunk editing: the `git add -p` command cannot rely on the internal diff machinery for coloring after letting the user edit a hunk; It has to "re-color" the edited hunk. This is the primary reason why that command is interested in the exact values of the `color.diff.*` settings in the first place. To test this re-coloring, we therefore have to pretend to edit a hunk and then show that hunk in the regression test. Co-authored-by: Jeff King <peff@peff.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-16 16:08:32 +00:00
test_expect_success 'colors can be overridden' '
git reset --hard &&
test_when_finished "git rm -f color-test" &&
test_write_lines context old more-context >color-test &&
git add color-test &&
test_write_lines context new more-context another-one >color-test &&
echo trigger an error message >input &&
force_color git \
-c color.interactive.error=blue \
add -i 2>err.raw <input &&
test_decode_color <err.raw >err &&
grep "<BLUE>Huh (trigger)?<RESET>" err &&
test_write_lines help quit >input &&
force_color git \
-c color.interactive.header=red \
-c color.interactive.help=green \
-c color.interactive.prompt=yellow \
add -i >actual.raw <input &&
test_decode_color <actual.raw >actual &&
cat >expect <<-\EOF &&
<RED> staged unstaged path<RESET>
1: +3/-0 +2/-1 color-test
<RED>*** Commands ***<RESET>
1: <YELLOW>s<RESET>tatus 2: <YELLOW>u<RESET>pdate 3: <YELLOW>r<RESET>evert 4: <YELLOW>a<RESET>dd untracked
5: <YELLOW>p<RESET>atch 6: <YELLOW>d<RESET>iff 7: <YELLOW>q<RESET>uit 8: <YELLOW>h<RESET>elp
<YELLOW>What now<RESET>> <GREEN>status - show paths with changes<RESET>
<GREEN>update - add working tree state to the staged set of changes<RESET>
<GREEN>revert - revert staged set of changes back to the HEAD version<RESET>
<GREEN>patch - pick hunks and update selectively<RESET>
<GREEN>diff - view diff between HEAD and index<RESET>
<GREEN>add untracked - add contents of untracked files to the staged set of changes<RESET>
<RED>*** Commands ***<RESET>
1: <YELLOW>s<RESET>tatus 2: <YELLOW>u<RESET>pdate 3: <YELLOW>r<RESET>evert 4: <YELLOW>a<RESET>dd untracked
5: <YELLOW>p<RESET>atch 6: <YELLOW>d<RESET>iff 7: <YELLOW>q<RESET>uit 8: <YELLOW>h<RESET>elp
<YELLOW>What now<RESET>> Bye.
EOF
test_cmp expect actual &&
: exercise recolor_hunk by editing and then look at the hunk again &&
test_write_lines s e K q >input &&
force_color git \
-c color.interactive.prompt=yellow \
-c color.diff.meta=italic \
-c color.diff.frag=magenta \
-c color.diff.context=cyan \
-c color.diff.old=bold \
-c color.diff.new=blue \
-c core.editor=touch \
add -p >actual.raw <input &&
test_decode_color <actual.raw >actual.decoded &&
sed "s/index [0-9a-f]*\\.\\.[0-9a-f]* 100644/<INDEX-LINE>/" <actual.decoded >actual &&
cat >expect <<-\EOF &&
<ITALIC>diff --git a/color-test b/color-test<RESET>
<ITALIC><INDEX-LINE><RESET>
<ITALIC>--- a/color-test<RESET>
<ITALIC>+++ b/color-test<RESET>
<MAGENTA>@@ -1,3 +1,4 @@<RESET>
<CYAN> context<RESET>
<BOLD>-old<RESET>
<BLUE>+<RESET><BLUE>new<RESET>
<CYAN> more-context<RESET>
<BLUE>+<RESET><BLUE>another-one<RESET>
<YELLOW>(1/1) Stage this hunk [y,n,q,a,d,s,e,?]? <RESET><BOLD>Split into 2 hunks.<RESET>
<MAGENTA>@@ -1,3 +1,3 @@<RESET>
<CYAN> context<RESET>
<BOLD>-old<RESET>
<BLUE>+<RESET><BLUE>new<RESET>
<CYAN> more-context<RESET>
<YELLOW>(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? <RESET><MAGENTA>@@ -3 +3,2 @@<RESET>
<CYAN> more-context<RESET>
<BLUE>+<RESET><BLUE>another-one<RESET>
<YELLOW>(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]? <RESET><MAGENTA>@@ -1,3 +1,3 @@<RESET>
<CYAN> context<RESET>
<BOLD>-old<RESET>
<BLUE>+new<RESET>
<CYAN> more-context<RESET>
<YELLOW>(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? <RESET>
EOF
test_cmp expect actual
'
test_expect_success 'brackets appear without color' '
git reset --hard &&
test_when_finished "git rm -f bracket-test" &&
test_write_lines context old more-context >bracket-test &&
git add bracket-test &&
test_write_lines context new more-context another-one >bracket-test &&
test_write_lines quit >input &&
git add -i >actual <input &&
sed "s/^|//" >expect <<-\EOF &&
| staged unstaged path
| 1: +3/-0 +2/-1 bracket-test
|
|*** Commands ***
| 1: [s]tatus 2: [u]pdate 3: [r]evert 4: [a]dd untracked
| 5: [p]atch 6: [d]iff 7: [q]uit 8: [h]elp
|What now> Bye.
EOF
test_cmp expect actual
'
test_expect_success 'colors can be skipped with color.ui=false' '
git reset --hard &&
test_when_finished "git rm -f color-test" &&
test_write_lines context old more-context >color-test &&
git add color-test &&
test_write_lines context new more-context another-one >color-test &&
test_write_lines help quit >input &&
force_color git \
-c color.ui=false \
add -i >actual.raw <input &&
test_decode_color <actual.raw >actual &&
test_cmp actual.raw actual
'
test_expect_success 'colorized diffs respect diff.wsErrorHighlight' '
git reset --hard &&
echo "old " >test &&
git add test &&
echo "new " >test &&
printf y >y &&
force_color git -c diff.wsErrorHighlight=all add -p >output.raw 2>&1 <y &&
test_decode_color <output.raw >output &&
grep "old<" output
'
test_expect_success 'diffFilter filters diff' '
git reset --hard &&
echo content >test &&
test_config interactive.diffFilter "sed s/^/foo:/" &&
printf y >y &&
force_color git add -p >output 2>&1 <y &&
# 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 'detect bogus diffFilter output' '
git reset --hard &&
echo content >test &&
test_config interactive.diffFilter "sed 6d" &&
printf y >y &&
force_color test_must_fail git add -p <y >output 2>&1 &&
grep "mismatched output" output
'
test_expect_success 'handle iffy colored hunk headers' '
git reset --hard &&
echo content >test &&
printf n >n &&
force_color git -c interactive.diffFilter="sed s/.*@@.*/XX/" \
add -p >output 2>&1 <n &&
grep "^XX$" output
'
pipe_command(): mark stdin descriptor as non-blocking Our pipe_command() helper lets you both write to and read from a child process on its stdin/stdout. It's supposed to work without deadlocks because we use poll() to check when descriptors are ready for reading or writing. But there's a bug: if both the data to be written and the data to be read back exceed the pipe buffer, we'll deadlock. The issue is that the code assumes that if you have, say, a 2MB buffer to write and poll() tells you that the pipe descriptor is ready for writing, that calling: write(cmd->in, buf, 2*1024*1024); will do a partial write, filling the pipe buffer and then returning what it did write. And that is what it would do on a socket, but not for a pipe. When writing to a pipe, at least on Linux, it will block waiting for the child process to read() more. And now we have a potential deadlock, because the child may be writing back to us, waiting for us to read() ourselves. An easy way to trigger this is: git -c add.interactive.useBuiltin=true \ -c interactive.diffFilter=cat \ checkout -p HEAD~200 The diff against HEAD~200 will be big, and the filter wants to write all of it back to us (obviously this is a dummy filter, but in the real world something like diff-highlight would similarly stream back a big output). If you set add.interactive.useBuiltin to false, the problem goes away, because now we're not using pipe_command() anymore (instead, that part happens in perl). But this isn't a bug in the interactive code at all. It's the underlying pipe_command() code which is broken, and has been all along. We presumably didn't notice because most calls only do input _or_ output, not both. And the few that do both, like gpg calls, may have large inputs or outputs, but never both at the same time (e.g., consider signing, which has a large payload but a small signature comes back). The obvious fix is to put the descriptor into non-blocking mode, and indeed, that makes the problem go away. Callers shouldn't need to care, because they never see the descriptor (they hand us a buffer to feed into it). The included test fails reliably on Linux without this patch. Curiously, it doesn't fail in our Windows CI environment, but has been reported to do so for individual developers. It should pass in any environment after this patch (courtesy of the compat/ layers added in the last few commits). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-08-17 06:10:22 +00:00
test_expect_success 'handle very large filtered diff' '
git reset --hard &&
# The specific number here is not important, but it must
# be large enough that the output of "git diff --color"
# fills up the pipe buffer. 10,000 results in ~200k of
# colored output.
test_seq 10000 >test &&
test_config interactive.diffFilter cat &&
printf y >y &&
force_color git add -p >output 2>&1 <y &&
git diff-files --exit-code -- test
'
test_expect_success 'diff.algorithm is passed to `git diff-files`' '
git reset --hard &&
>file &&
git add file &&
echo changed >file &&
test_must_fail git -c diff.algorithm=bogus add -p 2>err &&
test_i18ngrep "error: option diff-algorithm accepts " err
'
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 16:30:24 +00: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 09:16:56 +00: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 16:30:24 +00: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 16:30:24 +00: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 13:46:06 +00: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
EOF
test_cmp expected actual &&
git -C for-submodules diff-files --name-only --ignore-submodules=none >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 'handle submodules' '
echo 123 >>for-submodules/dirty-otherwise/initial.t &&
force_color git -C for-submodules add -p dirty-otherwise >output 2>&1 &&
grep "No changes" output &&
force_color git -C for-submodules add -p dirty-head >output 2>&1 <y &&
git -C for-submodules ls-files --stage dirty-head >actual &&
rev="$(git -C for-submodules/dirty-head rev-parse HEAD)" &&
grep "$rev" actual
'
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_expect_success 'checkout -p works with pathological context lines' '
test_write_lines a a a a a a >a &&
git add a &&
test_write_lines a b a b a b a b a b a >a &&
test_write_lines s n n y q | git checkout -p &&
test_write_lines a b a b a a b a b a >expect &&
test_cmp expect a
'
add -p: fix editing of intent-to-add paths A popular way of partially staging a new file is to run `git add -N <path>` and then use the hunk editing of `git add -p` to select the part of the file that the user wishes to stage. Since 85953a3187 ("diff-files --raw: show correct post-image of intent-to-add files", 2020-07-01) this has stopped working as intent-to-add paths are now show as new files rather than changes to an empty blob and `git apply` refused to apply a creation patch for a path that was marked as intent-to-add. 7cfde3fa0f ("apply: allow "new file" patches on i-t-a entries", 2020-08-06) fixed the problem with apply but it still wasn't possible to edit the added hunk properly. 2c8bd8471a ("checkout -p: handle new files correctly", 2020-05-27) had previously changed `add -p` to handle new files but it did not implement patch editing correctly. The perl version simply forbade editing and the C version opened the editor with the full diff rather that just the hunk which meant that the user had to edit the hunk header manually to get it to work. The root cause of the problem is that added files store the diff header with the hunk data rather than separating the two as we do for other changes. Changing added files to store the diff header separately fixes the editing problem at the expense of having to special case empty additions as they no longer have any hunks associated with them, only the diff header. The changes move some existing code into a conditional changing the indentation, they are best viewed with --color-moved-ws=allow-indentation-change (or --ignore-space-change works well to get an overview of the changes) Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Reported-by: Thomas Sullivan <tom@msbit.com.au> Reported-by: Yuchen Ying <ych@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-09 13:58:52 +00:00
# This should be called from a subshell as it sets a temporary editor
setup_new_file() {
write_script new-file-editor.sh <<-\EOF &&
sed /^#/d "$1" >patch &&
sed /^+c/d patch >"$1"
EOF
test_set_editor "$(pwd)/new-file-editor.sh" &&
test_write_lines a b c d e f >new-file &&
test_write_lines a b d e f >new-file-expect &&
test_write_lines "@@ -0,0 +1,6 @@" +a +b +c +d +e +f >patch-expect
}
test_expect_success 'add -N followed by add -p patch editing' '
git reset --hard &&
(
setup_new_file &&
git add -N new-file &&
test_write_lines e n q | git add -p &&
git cat-file blob :new-file >actual &&
test_cmp new-file-expect actual &&
test_cmp patch-expect patch
)
'
test_expect_success 'checkout -p patch editing of added file' '
git reset --hard &&
(
setup_new_file &&
git add new-file &&
git commit -m "add new file" &&
git rm new-file &&
git commit -m "remove new file" &&
test_write_lines e n q | git checkout -p HEAD^ &&
test_cmp new-file-expect new-file &&
test_cmp patch-expect patch
)
'
test_expect_success 'show help from add--helper' '
git reset --hard &&
cat >expect <<-EOF &&
<BOLD>*** Commands ***<RESET>
1: <BOLD;BLUE>s<RESET>tatus 2: <BOLD;BLUE>u<RESET>pdate 3: <BOLD;BLUE>r<RESET>evert 4: <BOLD;BLUE>a<RESET>dd untracked
5: <BOLD;BLUE>p<RESET>atch 6: <BOLD;BLUE>d<RESET>iff 7: <BOLD;BLUE>q<RESET>uit 8: <BOLD;BLUE>h<RESET>elp
<BOLD;BLUE>What now<RESET>> <BOLD;RED>status - show paths with changes<RESET>
<BOLD;RED>update - add working tree state to the staged set of changes<RESET>
<BOLD;RED>revert - revert staged set of changes back to the HEAD version<RESET>
<BOLD;RED>patch - pick hunks and update selectively<RESET>
<BOLD;RED>diff - view diff between HEAD and index<RESET>
<BOLD;RED>add untracked - add contents of untracked files to the staged set of changes<RESET>
<BOLD>*** Commands ***<RESET>
1: <BOLD;BLUE>s<RESET>tatus 2: <BOLD;BLUE>u<RESET>pdate 3: <BOLD;BLUE>r<RESET>evert 4: <BOLD;BLUE>a<RESET>dd untracked
5: <BOLD;BLUE>p<RESET>atch 6: <BOLD;BLUE>d<RESET>iff 7: <BOLD;BLUE>q<RESET>uit 8: <BOLD;BLUE>h<RESET>elp
<BOLD;BLUE>What now<RESET>>$SP
Bye.
EOF
test_write_lines h | force_color git add -i >actual.colored &&
test_decode_color <actual.colored >actual &&
test_cmp expect actual
'
add-patch: handle "* Unmerged path" lines When we generate a diff with --cached, unmerged entries have no oid for their index entry: $ git diff-index --abbrev --cached HEAD :100644 000000 f719efd 0000000 U my-conflict So when we are asked to produce a patch, since we only have one side, we just emit a special message: $ git diff-index --cached -p HEAD * Unmerged path my-conflict This confuses interactive-patch modes that look at cached diffs. For example: $ git reset -p BUG: add-patch.c:498: diff starts with unexpected line: * Unmerged path my-conflict Making things even more confusing, you'll get that error only if the unmerged entry is alphabetically the first changed file. Otherwise, we simply stick the unrecognized line to the end of the previous hunk. There it's mostly harmless, as it eventually gets fed back to "git apply", which happily ignores it. But it's still shown to the user attached to the hunk, which is wrong. So let's handle these lines as a noop. There's not really anything useful to do with a conflicted merge in this case, and that's what we do for other cases like "add -p". There we get a "diff --cc" line, which we accept as starting a new file, but we refuse to use any of its hunks (their headers start with "@@@" and not "@@ ", so we silently ignore them). It seems like simply recognizing the line and continuing in our parsing loop would work. But we actually need to run the rest of the loop body to handle matching up our colored/filtered output. But that code assumes that we have some active file_diff we're working on. So instead, we'll just insert a dummy entry into our array. This ends up the same as if we saw a "diff --cc" line (a file with no hunks). Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-09 08:58:16 +00:00
test_expect_success 'reset -p with unmerged files' '
test_when_finished "git checkout --force main" &&
test_commit one conflict &&
git checkout -B side HEAD^ &&
test_commit two conflict &&
test_must_fail git merge one &&
# this is a noop with only an unmerged entry
git reset -p &&
# add files that sort before and after unmerged entry
echo a >a &&
echo z >z &&
git add a z &&
# confirm that we can reset those files
printf "%s\n" y y | git reset -p &&
git diff-index --cached --diff-filter=u HEAD >staged &&
test_must_be_empty staged
'
test_done