2008-02-13 13:50:51 +03:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='add -i basic tests'
|
|
|
|
. ./test-lib.sh
|
2017-10-03 16:42:15 +03:00
|
|
|
. "$TEST_DIRECTORY"/lib-terminal.sh
|
2008-02-13 13:50:51 +03:00
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
if ! test_have_prereq PERL
|
|
|
|
then
|
|
|
|
skip_all='skipping add -i tests, perl not available'
|
|
|
|
test_done
|
|
|
|
fi
|
|
|
|
|
2018-03-01 13:50:58 +03:00
|
|
|
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"
|
|
|
|
}
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup (initial)' '
|
2008-02-13 13:50:51 +03:00
|
|
|
echo content >file &&
|
|
|
|
git add file &&
|
|
|
|
echo more >>file &&
|
|
|
|
echo lines >>file
|
|
|
|
'
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'status works (initial)' '
|
2008-02-13 13:50:51 +03:00
|
|
|
git add -i </dev/null >output &&
|
|
|
|
grep "+1/-0 *+2/-0 file" output
|
|
|
|
'
|
2010-08-14 00:40:05 +04:00
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup expected' '
|
2018-02-19 14:29:03 +03:00
|
|
|
cat >expected <<-\EOF
|
|
|
|
new file mode 100644
|
|
|
|
index 0000000..d95f3ad
|
|
|
|
--- /dev/null
|
|
|
|
+++ b/file
|
|
|
|
@@ -0,0 +1 @@
|
|
|
|
+content
|
|
|
|
EOF
|
2010-08-14 00:40:05 +04:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'diff works (initial)' '
|
2018-07-02 03:23:42 +03:00
|
|
|
test_write_lines d 1 | git add -i >output &&
|
2008-02-13 13:50:51 +03:00
|
|
|
sed -ne "/new file/,/content/p" <output >diff &&
|
2018-03-01 13:50:58 +03:00
|
|
|
diff_cmp expected diff
|
2008-02-13 13:50:51 +03:00
|
|
|
'
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'revert works (initial)' '
|
2008-02-13 13:50:51 +03:00
|
|
|
git add file &&
|
2018-07-02 03:23:42 +03:00
|
|
|
test_write_lines r 1 | git add -i &&
|
2008-02-13 13:50:51 +03:00
|
|
|
git ls-files >output &&
|
|
|
|
! grep . output
|
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup (commit)' '
|
2008-02-13 13:50:51 +03:00
|
|
|
echo baseline >file &&
|
|
|
|
git add file &&
|
|
|
|
git commit -m commit &&
|
|
|
|
echo content >>file &&
|
|
|
|
git add file &&
|
|
|
|
echo more >>file &&
|
|
|
|
echo lines >>file
|
|
|
|
'
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'status works (commit)' '
|
2008-02-13 13:50:51 +03:00
|
|
|
git add -i </dev/null >output &&
|
|
|
|
grep "+1/-0 *+2/-0 file" output
|
|
|
|
'
|
2010-08-14 00:40:05 +04:00
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup expected' '
|
2018-02-19 14:29:03 +03:00
|
|
|
cat >expected <<-\EOF
|
|
|
|
index 180b47c..b6f2c08 100644
|
|
|
|
--- a/file
|
|
|
|
+++ b/file
|
|
|
|
@@ -1 +1,2 @@
|
|
|
|
baseline
|
|
|
|
+content
|
|
|
|
EOF
|
2010-08-14 00:40:05 +04:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'diff works (commit)' '
|
2018-07-02 03:23:42 +03:00
|
|
|
test_write_lines d 1 | git add -i >output &&
|
2008-02-13 13:50:51 +03:00
|
|
|
sed -ne "/^index/,/content/p" <output >diff &&
|
2018-03-01 13:50:58 +03:00
|
|
|
diff_cmp expected diff
|
2008-02-13 13:50:51 +03:00
|
|
|
'
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'revert works (commit)' '
|
2008-02-13 13:50:51 +03:00
|
|
|
git add file &&
|
2018-07-02 03:23:42 +03:00
|
|
|
test_write_lines r 1 | git add -i &&
|
2008-02-13 13:50:51 +03:00
|
|
|
git add -i </dev/null >output &&
|
|
|
|
grep "unchanged *+3/-0 file" output
|
|
|
|
'
|
|
|
|
|
2010-08-14 00:40:05 +04:00
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup expected' '
|
2018-02-19 14:29:03 +03:00
|
|
|
cat >expected <<-\EOF
|
|
|
|
EOF
|
2010-08-14 00:40:05 +04:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'dummy edit works' '
|
2018-02-19 14:29:04 +03:00
|
|
|
test_set_editor : &&
|
2018-07-02 03:23:42 +03:00
|
|
|
test_write_lines e a | git add -p &&
|
2008-07-03 02:00:00 +04:00
|
|
|
git diff > diff &&
|
2018-03-01 13:50:58 +03:00
|
|
|
diff_cmp expected diff
|
2008-07-03 02:00:00 +04:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup patch' '
|
2018-02-19 14:29:03 +03:00
|
|
|
cat >patch <<-\EOF
|
|
|
|
@@ -1,1 +1,4 @@
|
|
|
|
this
|
|
|
|
+patch
|
|
|
|
-does not
|
|
|
|
apply
|
|
|
|
EOF
|
2010-08-14 00:40:05 +04:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup fake editor' '
|
2018-02-19 14:29:04 +03:00
|
|
|
write_script "fake_editor.sh" <<-\EOF &&
|
2018-02-19 14:29:03 +03:00
|
|
|
mv -f "$1" oldpatch &&
|
|
|
|
mv -f patch "$1"
|
|
|
|
EOF
|
2010-08-14 00:40:05 +04:00
|
|
|
test_set_editor "$(pwd)/fake_editor.sh"
|
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'bad edit rejected' '
|
2008-07-03 02:00:00 +04:00
|
|
|
git reset &&
|
2018-07-02 03:23:42 +03:00
|
|
|
test_write_lines e n d | git add -p >output &&
|
2008-07-03 02:00:00 +04:00
|
|
|
grep "hunk does not apply" output
|
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup patch' '
|
2018-02-19 14:29:03 +03:00
|
|
|
cat >patch <<-\EOF
|
|
|
|
this patch
|
|
|
|
is garbage
|
|
|
|
EOF
|
2010-08-14 00:40:05 +04:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'garbage edit rejected' '
|
2008-07-03 02:00:00 +04:00
|
|
|
git reset &&
|
2018-07-02 03:23:42 +03:00
|
|
|
test_write_lines e n d | git add -p >output &&
|
2008-07-03 02:00:00 +04:00
|
|
|
grep "hunk does not apply" output
|
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup patch' '
|
2018-02-19 14:29:03 +03:00
|
|
|
cat >patch <<-\EOF
|
|
|
|
@@ -1,0 +1,0 @@
|
|
|
|
baseline
|
|
|
|
+content
|
|
|
|
+newcontent
|
|
|
|
+lines
|
|
|
|
EOF
|
2010-08-14 00:40:05 +04:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup expected' '
|
2018-02-19 14:29:03 +03:00
|
|
|
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
|
2010-08-14 00:40:05 +04:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'real edit works' '
|
2018-07-02 03:23:42 +03:00
|
|
|
test_write_lines e n d | git add -p &&
|
2008-07-03 02:00:00 +04:00
|
|
|
git diff >output &&
|
2018-03-01 13:50:58 +03:00
|
|
|
diff_cmp expected output
|
2008-07-03 02:00:00 +04:00
|
|
|
'
|
|
|
|
|
2018-06-11 12:46:02 +03:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'skip files similarly as commit -a' '
|
2009-10-10 19:51:45 +04:00
|
|
|
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 &&
|
2018-03-01 13:50:58 +03:00
|
|
|
diff_cmp expected output &&
|
2009-10-10 19:51:45 +04:00
|
|
|
git reset --hard HEAD^
|
|
|
|
'
|
|
|
|
rm -f .gitignore
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success FILEMODE 'patch does not affect mode' '
|
2008-03-27 10:30:43 +03:00
|
|
|
git reset --hard &&
|
|
|
|
echo content >>file &&
|
|
|
|
chmod +x file &&
|
2008-03-27 10:32:25 +03:00
|
|
|
printf "n\\ny\\n" | git add -p &&
|
2008-03-27 10:30:43 +03:00
|
|
|
git show :file | grep content &&
|
|
|
|
git diff file | grep "new mode"
|
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success FILEMODE 'stage mode but not hunk' '
|
2008-03-27 10:32:25 +03:00
|
|
|
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"
|
|
|
|
'
|
|
|
|
|
git add -p: demonstrate failure when staging both mode and hunk
When trying to stage changes to file which has also pending `chmod +x`,
`git add -p` produces lots of 'Use of uninitialized value ...' warnings
and fails to do the job:
$ echo content >> file
$ chmod +x file
$ git add -p
diff --git a/file b/file
index e69de29..d95f3ad
--- a/file
+++ b/file
old mode 100644
new mode 100755
Stage mode change [y,n,q,a,d,/,j,J,g,?]? y
@@ -0,0 +1 @@
+content
Stage this hunk [y,n,q,a,d,/,K,g,e,?]? y
Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
Use of uninitialized value $ofs in numeric le (<=) at .../git-add--interactive line 806.
Use of uninitialized value $o0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
Use of uninitialized value $n0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
fatal: corrupt patch at line 5
diff --git a/file b/file
index e69de29..d95f3ad
--- a/file
+++ b/file
@@ -,0 + @@
+content
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-15 16:26:49 +04:00
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success FILEMODE 'stage mode and hunk' '
|
git add -p: demonstrate failure when staging both mode and hunk
When trying to stage changes to file which has also pending `chmod +x`,
`git add -p` produces lots of 'Use of uninitialized value ...' warnings
and fails to do the job:
$ echo content >> file
$ chmod +x file
$ git add -p
diff --git a/file b/file
index e69de29..d95f3ad
--- a/file
+++ b/file
old mode 100644
new mode 100755
Stage mode change [y,n,q,a,d,/,j,J,g,?]? y
@@ -0,0 +1 @@
+content
Stage this hunk [y,n,q,a,d,/,K,g,e,?]? y
Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
Use of uninitialized value $ofs in numeric le (<=) at .../git-add--interactive line 806.
Use of uninitialized value $o0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
Use of uninitialized value $n0_ofs in concatenation (.) or string at .../git-add--interactive line 830.
Use of uninitialized value $o_ofs in addition (+) at .../git-add--interactive line 776.
fatal: corrupt patch at line 5
diff --git a/file b/file
index e69de29..d95f3ad
--- a/file
+++ b/file
@@ -,0 + @@
+content
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-15 16:26:49 +04:00
|
|
|
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)"
|
|
|
|
'
|
|
|
|
|
2008-05-21 01:59:32 +04:00
|
|
|
# end of tests disabled when filemode is not usable
|
2008-03-27 10:32:25 +03:00
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup again' '
|
2009-05-25 16:07:55 +04:00
|
|
|
git reset --hard &&
|
|
|
|
test_chmod +x file &&
|
|
|
|
echo content >>file
|
|
|
|
'
|
|
|
|
|
2009-05-16 07:10:19 +04:00
|
|
|
# Write the patch file with a new line at the top and bottom
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup patch' '
|
2018-02-19 14:29:03 +03:00
|
|
|
cat >patch <<-\EOF
|
|
|
|
index 180b47c..b6f2c08 100644
|
|
|
|
--- a/file
|
|
|
|
+++ b/file
|
|
|
|
@@ -1,2 +1,4 @@
|
|
|
|
+firstline
|
|
|
|
baseline
|
|
|
|
content
|
|
|
|
+lastline
|
2018-03-05 13:56:29 +03:00
|
|
|
\ No newline at end of file
|
2018-02-19 14:29:03 +03:00
|
|
|
EOF
|
2010-08-14 00:40:05 +04:00
|
|
|
'
|
|
|
|
|
2018-03-05 13:56:29 +03:00
|
|
|
# Expected output, diff is similar to the patch but w/ diff at the top
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup expected' '
|
2018-03-05 13:56:29 +03:00
|
|
|
echo diff --git a/file b/file >expected &&
|
|
|
|
cat patch |sed "/^index/s/ 100644/ 100755/" >>expected &&
|
|
|
|
cat >expected-output <<-\EOF
|
2018-02-19 14:29:03 +03:00
|
|
|
--- a/file
|
|
|
|
+++ b/file
|
|
|
|
@@ -1,2 +1,4 @@
|
|
|
|
+firstline
|
|
|
|
baseline
|
|
|
|
content
|
|
|
|
+lastline
|
2018-03-05 13:56:29 +03:00
|
|
|
\ 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
|
2018-02-19 14:29:03 +03:00
|
|
|
EOF
|
2010-08-14 00:40:05 +04:00
|
|
|
'
|
|
|
|
|
2009-05-16 07:10:19 +04:00
|
|
|
# Test splitting the first patch, then adding both
|
2018-03-05 13:56:29 +03:00
|
|
|
test_expect_success C_LOCALE_OUTPUT 'add first line works' '
|
2009-05-16 07:10:19 +04:00
|
|
|
git commit -am "clear local changes" &&
|
|
|
|
git apply patch &&
|
2018-03-05 13:56:29 +03:00
|
|
|
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
|
2009-05-16 07:10:19 +04:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup expected' '
|
2018-02-19 14:29:03 +03:00
|
|
|
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
|
2010-08-14 00:40:05 +04:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'deleting a non-empty file' '
|
2009-12-08 10:49:35 +03:00
|
|
|
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 &&
|
2018-03-01 13:50:58 +03:00
|
|
|
diff_cmp expected diff
|
2009-12-08 10:49:35 +03:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'setup expected' '
|
2018-02-19 14:29:03 +03:00
|
|
|
cat >expected <<-\EOF
|
|
|
|
diff --git a/empty b/empty
|
|
|
|
deleted file mode 100644
|
|
|
|
index e69de29..0000000
|
|
|
|
EOF
|
2010-08-14 00:40:05 +04:00
|
|
|
'
|
2009-10-28 03:52:57 +03:00
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'deleting an empty file' '
|
2009-10-28 03:52:57 +03:00
|
|
|
git reset --hard &&
|
|
|
|
> empty &&
|
|
|
|
git add empty &&
|
|
|
|
git commit -m empty &&
|
|
|
|
rm empty &&
|
|
|
|
echo y | git add -p empty &&
|
|
|
|
git diff --cached >diff &&
|
2018-03-01 13:50:58 +03:00
|
|
|
diff_cmp expected diff
|
2009-10-28 03:52:57 +03:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'split hunk setup' '
|
2011-04-29 23:41:16 +04:00
|
|
|
git reset --hard &&
|
2018-02-19 14:29:04 +03:00
|
|
|
test_write_lines 10 20 30 40 50 60 >test &&
|
2011-04-29 23:41:16 +04:00
|
|
|
git add test &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m test &&
|
|
|
|
|
2018-02-19 14:29:04 +03:00
|
|
|
test_write_lines 10 15 20 21 22 23 24 30 40 50 60 >test
|
2011-04-29 23:41:16 +04:00
|
|
|
'
|
|
|
|
|
2013-08-25 00:13:32 +04:00
|
|
|
test_expect_success 'split hunk "add -p (edit)"' '
|
2011-04-29 23:41:16 +04:00
|
|
|
# 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
|
2013-04-12 02:36:10 +04:00
|
|
|
# about the next hunk, against which we say q and program
|
2011-04-29 23:41:16 +04:00
|
|
|
# exits.
|
2015-04-16 10:02:27 +03:00
|
|
|
printf "%s\n" s e q n q q |
|
2011-04-29 23:41:16 +04:00
|
|
|
EDITOR=: git add -p &&
|
|
|
|
git diff >actual &&
|
|
|
|
! grep "^+15" actual
|
|
|
|
'
|
|
|
|
|
2015-04-16 10:02:28 +03:00
|
|
|
test_expect_failure 'split hunk "add -p (no, yes, edit)"' '
|
2018-02-19 14:29:04 +03:00
|
|
|
test_write_lines 5 10 20 21 30 31 40 50 60 >test &&
|
2015-04-16 10:02:28 +03:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
add--interactive: ignore unmerged entries in patch mode
When "add -p" sees an unmerged entry, it shows the combined
diff and then immediately skips the hunk. This can be
confusing in a variety of ways, depending on whether there
are other changes to stage (in which case you get the
superfluous combined diff output in between other hunks) or
not (in which case you get the combined diff and the program
exits immediately, rather than seeing "No changes").
The current behavior was not planned, and is just what the
implementation happens to do. Instead, let's explicitly
remove unmerged entries from our list of modified files, and
print a warning that we are ignoring them.
We can cheaply find which entries are unmerged by adding
"--raw" output to the "diff-files --numstat" we already run.
There is one non-obvious thing we must change when parsing
this combined output. Before this patch, when we saw a
numstat line for a file that did not have index changes, we
would create a new record with 'unchanged' in the 'INDEX'
field. Because "--raw" comes before "--numstat", we must
move this special-case down to the raw-line case (and it is
sufficient to move it rather than handle it in both places,
since any file which has a --numstat will also have a --raw
entry).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-05 16:30:08 +04:00
|
|
|
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 &&
|
2018-03-01 13:50:58 +03:00
|
|
|
diff_cmp expected diff
|
add--interactive: ignore unmerged entries in patch mode
When "add -p" sees an unmerged entry, it shows the combined
diff and then immediately skips the hunk. This can be
confusing in a variety of ways, depending on whether there
are other changes to stage (in which case you get the
superfluous combined diff output in between other hunks) or
not (in which case you get the combined diff and the program
exits immediately, rather than seeing "No changes").
The current behavior was not planned, and is just what the
implementation happens to do. Instead, let's explicitly
remove unmerged entries from our list of modified files, and
print a warning that we are ignoring them.
We can cheaply find which entries are unmerged by adding
"--raw" output to the "diff-files --numstat" we already run.
There is one non-obvious thing we must change when parsing
this combined output. Before this patch, when we saw a
numstat line for a file that did not have index changes, we
would create a new record with 'unchanged' in the 'INDEX'
field. Because "--raw" comes before "--numstat", we must
move this special-case down to the raw-line case (and it is
sufficient to move it rather than handle it in both places,
since any file which has a --numstat will also have a --raw
entry).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-05 16:30:08 +04:00
|
|
|
'
|
|
|
|
|
2017-10-03 16:42:15 +03:00
|
|
|
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 03:21:29 +03:00
|
|
|
git reset --hard &&
|
|
|
|
|
|
|
|
echo content >test &&
|
2017-10-03 16:42:15 +03:00
|
|
|
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 03:21:29 +03: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
|
|
|
|
'
|
|
|
|
|
2018-03-03 08:58:10 +03:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2018-03-03 08:58:49 +03:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2017-03-02 12:48:22 +03:00
|
|
|
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 &&
|
2018-03-01 13:50:58 +03:00
|
|
|
diff_cmp expect actual
|
2017-03-02 12:48:22 +03:00
|
|
|
'
|
|
|
|
|
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 19:30:24 +03: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 12:16:56 +03: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 19:30:24 +03: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".
|
t3701-add-interactive: tighten the check of trace output
The test 'add -p does not expand argument lists' in
't3701-add-interactive.sh', added in 7288e12cce (add--interactive: do
not expand pathspecs with ls-files, 2017-03-14), checks the GIT_TRACE
of 'git add -p' to ensure that the name of a tracked file wasn't
passed around as argument to any of the commands executed as a result
of undesired pathspec expansion. This check is done with 'grep' using
the filename on its own as the pattern, which is too loose a pattern,
and would match any occurrences of the filename in the trace output,
not just those as command arguments. E.g. if a developer were to
litter the index handling code with trace_printf()s printing, among
other things, the name of the just processed cache entry, then that
pattern would mistakenly match these as well, and would fail the test.
Tighten this 'grep' pattern to only match trace lines that show the
executed commands.
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-10 17:07:14 +03:00
|
|
|
! 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 19:30:24 +03:00
|
|
|
'
|
|
|
|
|
2017-06-21 22:28:59 +03: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 16:46:06 +03: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
|
|
|
|
'
|
|
|
|
|
2018-01-13 15:10:38 +03:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2018-03-01 13:50:59 +03:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2018-03-01 13:51:00 +03:00
|
|
|
test_expect_success 'add -p works with pathological context lines' '
|
2018-03-01 13:50:59 +03:00
|
|
|
git reset &&
|
|
|
|
printf "%s\n" n y |
|
|
|
|
git add -p &&
|
|
|
|
git cat-file blob :a >actual &&
|
|
|
|
test_cmp expected-1 actual
|
|
|
|
'
|
|
|
|
|
2018-03-05 13:56:28 +03:00
|
|
|
test_expect_success 'add -p patch editing works with pathological context lines' '
|
2018-03-01 13:50:59 +03:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
2008-02-13 13:50:51 +03:00
|
|
|
test_done
|