On Mon, May 11, 2009 at 03:28:58PM -0400, Don Slutz wrote:
> diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
> index e768c3e..bf39e45 100755
> --- a/t/t7610-mergetool.sh
> +++ b/t/t7610-mergetool.sh
> @@ -45,9 +45,9 @@ test_expect_success 'custom mergetool' '
> ( yes "" | git mergetool file1 >/dev/null 2>&1 ) &&
> ( yes "" | git mergetool file2 >/dev/null 2>&1 ) &&
> ( yes "" | git mergetool subdir/file3 >/dev/null 2>&1 ) &&
> - test "$(cat file1)" = "master updated" &&
> - test "$(cat file2)" = "master new" &&
> - test "$(cat subdir/file3)" = "master new sub" &&
> + test_cat_eq file1 "master updated" &&
> + test_cat_eq file2 "master new" &&
> + test_cat_eq subdir/file3 "master new sub" &&
> git commit -m "branch1 resolved with mergetool"
> '
This change concerns me. At the moment, the mergetool test assumes
that globally autocrlf is true and has further tests that attempt to
verify its behaviour with autocrlf set to true. See the very next
test:
test_expect_success 'mergetool crlf' '
git config core.autocrlf true &&
git checkout -b test2 branch1
test_must_fail git merge master >/dev/null 2>&1 &&
( yes "" | git mergetool file1 >/dev/null 2>&1 ) &&
( yes "" | git mergetool file2 >/dev/null 2>&1 ) &&
( yes "" | git mergetool subdir/file3 >/dev/null 2>&1 ) &&
test "$(printf x | cat file1 -)" = "$(printf "master updated\r\nx")" &&
test "$(printf x | cat file2 -)" = "$(printf "master new\r\nx")" &&
test "$(printf x | cat subdir/file3 -)" = "$(printf "master new sub\r\nx")" &&
git commit -m "branch1 resolved with mergetool - autocrlf" &&
git config core.autocrlf false &&
git reset --hard
'
Does the resetting of core.autocrlf to false not break the subsequent
tests?
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
--
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