On 3/14/07, Junio C Hamano <junkio@xxxxxxx> wrote:
> - return run_diff_files_cmd(&rev, argc, argv);
> + result = run_diff_files_cmd(&rev, argc, argv);
> + return rev.diffopt.diff_exit_code ? rev.diffopt.exit_code: result;
> }
Yuck. Let's call the former "exit_with_status" (meaning, the
caller instructed us to do that) and the latter "has_changes".
I like "exit_with_status". But has_changes looks confusing
good near return value of run_diff_files_cmd, which "has"
nothing. Or do you mean to highlight this "difference"?
> +test_expect_failure 'git diff-index --cached HEAD^' '
> + echo text >>b &&
> + echo 3 >c &&
> + git add . &&
> + git diff-index --exit-code --cached HEAD^
> +'
Please:
test_expect_success '...
echo ... &&
git add . &&
! git diff-index ...
'
I recall somebody on the list had a buggy shell that cannot
handle "a && ! b" and tweaked a few tests to work around it.
In that case...
echo ... &&
git add . &&
{
git diff-index ...; test $? != 0
}
Confused. What's wrong with test_expect_failure which
does not need any of the both ugly constructions?
Hmm... Do you mean: "we expect successful
operation with exit code 1"? I like this, easier to follow.
Will do.
> +test_expect_failure 'git diff-files' '
> + echo 3 >>c &&
> + git diff-files --exit-code
> +'
Likewise
Yep, I'll change this too.
> +git update-index c || error "update-index failed"
Please do not have command outside test_expect without good
reason.
Well, it does not actually belongs to the test logic
(as well as the echo's, one may notice).
-
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