When testing aliases in t/t1020-subdirectory.sh use longer names so that they're less likely to conflict with a git-* command somewhere in the $PATH. I have a git-ss command in my path which prevents the 'ss' alias from being used. This command will always fail for git.git, causing the test to fail. Even if the command succeeded, that would be a false success for the test since the alias wasn't actually used. A longer, more descriptive name will make it much less likely that somebody has a command in their $PATH which will shadow the alias created for the test. While here, use a longer name for the 'test' alias as well since that is also short and meaningful enough to make it not unlikely that somebody would have a command in their $PATH which will shadow that as well. Signed-off-by: Aaron Schrab <aaron@xxxxxxxxxx> --- t/t1020-subdirectory.sh | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/t/t1020-subdirectory.sh b/t/t1020-subdirectory.sh index e23ac0e..1e2945e 100755 --- a/t/t1020-subdirectory.sh +++ b/t/t1020-subdirectory.sh @@ -111,19 +111,19 @@ test_expect_success 'read-tree' ' test_expect_success 'alias expansion' ' ( - git config alias.ss status && + git config alias.test-status-alias status && cd dir && git status && - git ss + git test-status-alias ) ' test_expect_success NOT_MINGW '!alias expansion' ' pwd >expect && ( - git config alias.test !pwd && + git config alias.test-alias-directory !pwd && cd dir && - git test >../actual + git test-alias-directory >../actual ) && test_cmp expect actual ' @@ -131,9 +131,9 @@ test_expect_success NOT_MINGW '!alias expansion' ' test_expect_success 'GIT_PREFIX for !alias' ' printf "dir/" >expect && ( - git config alias.test "!sh -c \"printf \$GIT_PREFIX\"" && + git config alias.test-alias-directory "!sh -c \"printf \$GIT_PREFIX\"" && cd dir && - git test >../actual + git test-alias-directory >../actual ) && test_cmp expect actual ' -- 1.8.1.rc3.16.g47d6ba6 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html