Piotr Krukowiecki [off-list ref] writes:
Now I don't know how should I handle this:
1. unset it just before "git stash apply" in my test
A safe, local change
This is the preferred method; in addition to "a safe local", more
importantly, at that point you are testing what you _want_ to be testing,
namely, how the output appears to the _real_ end users who do not use
verbose message. So for that purpose, mucking locally with MERGE_VERBOSITY
is perfectly acceptable.
You would not just "unset it just before", but "unset around it" in a
subshell like this:
git stash &&
(
sane_unset GIT_MERGE_VERBOSITY &&
git stash apply
) >../actual &&
git status >../expect &&
test_cmp ../expect ../actual
so that if somebody adds new tests later in the script, they are not
affected by this change.
Write your test_cmp always to compare expected with actual, not the other
way around, so that the diff output you see when the test is run under -v
option shows the changes from what is expected.
Thanks.
W dniu 17.03.2011 20:30, Junio C Hamano pisze:
Piotr Krukowiecki [off-list ref] writes:
quoted
Now I don't know how should I handle this:
1. unset it just before "git stash apply" in my test
A safe, local change
This is the preferred method; in addition to "a safe local", more
importantly, at that point you are testing what you _want_ to be testing,
namely, how the output appears to the _real_ end users who do not use
verbose message. So for that purpose, mucking locally with MERGE_VERBOSITY
is perfectly acceptable.
You would not just "unset it just before", but "unset around it" in a
subshell like this:
git stash &&
(
sane_unset GIT_MERGE_VERBOSITY &&
git stash apply
) >../actual &&
git status >../expect &&
test_cmp ../expect ../actual
so that if somebody adds new tests later in the script, they are not
affected by this change.
Write your test_cmp always to compare expected with actual, not the other
way around, so that the diff output you see when the test is run under -v
option shows the changes from what is expected.
Thanks.
Thanks, updated according to your suggestions.
I've also added a check to see if the output contains a relative path
(so we really test not only that git-stash shows the same status
as git-status, but that the paths are relative).
I'm not resending the original patch for git-stash.sh - I don't know if
it's expected to always send full set of patches?
---8<---
From: Piotr Krukowiecki <redacted>
Date: Mon, 14 Mar 2011 20:19:36 +0100
Subject: [PATCH 2/2] Add test: git stash shows status relative to current dir
Signed-off-by: Piotr Krukowiecki <redacted>
---
t/t3903-stash.sh | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 6fd560c..13f9ae8 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -556,4 +556,23 @@ test_expect_success 'stash branch should not drop the stash if the branch exists
git rev-parse stash@{0} --
'
+test_expect_success 'stash apply shows status same as git status (relative to current directory)' '
+ git stash clear &&
+ echo 1 > subdir/subfile1 &&
+ echo 2 > subdir/subfile2 &&
+ git add subdir/subfile1 &&
+ git commit -m subdir &&
+ cd subdir &&
+ echo x > subfile1 &&
+ echo x > ../file &&
+ git stash &&
+ (
+ sane_unset GIT_MERGE_VERBOSITY &&
+ git stash apply
+ ) > ../actual &&
+ git status > ../expect &&
+ test_cmp ../expect ../actual &&
+ grep "[.][.]/actual" ../actual
+'
+
test_done--
1.7.4.1.296.gca6da
--
Piotr Krukowiecki