I'll have to let Ãvar respond to most of these, but two quick items...
On Sun, Oct 3, 2010 at 8:13 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> Elijah Newren wrote:
>
>> --- a/t/README
>> +++ b/t/README
>> @@ -482,6 +475,15 @@ library for your script to use.
>> Â Â Â Â Â 'Perl API' \
>> Â Â Â Â Â "$PERL_PATH" "$TEST_DIRECTORY"/t9700/test.pl
>>
>> + - test_expect_code <exit-code> <git-command>
>> +
>> + Â Run a git command and ensure that it exits with the given exit
>> + Â code. For example:
>> +
>> + Â Â test_expect_success 'Merge with d/f conflicts' '
>> + Â Â Â Â Â Â test_expect_code 1 git merge "merge msg" B master
>> + Â Â '
>
> Side note: this helper should be safe to use even for non-git
> commands. Â"Huh?" you might ask. "But test_must_fail and
> test_might_fail..." ÂWell, the distinction is this: test_must_fail and
> test_might_fail rely on details of git's funny exit code conventions
> --- e.g., that 130 is not a controlled failure and 129 is one ---
> while test_expect_code has simpler, more generally valid semantics.
>
> But maybe in practice this helper would only be used for git commands
> anyway.
Perhaps, but I agree that it at least makes sense to be used by other
commands, so I'll change the documentation here to replace "git
commands" with just "commands".
[...]
>> +test_expect_code () {
>> + Â Â want_code=$1
>> + Â Â shift
>> + Â Â "$@"
>> + Â Â exit_code=$?
>> + Â Â if test $exit_code = $want_code
>> + Â Â then
>> + Â Â Â Â Â Â echo >&2 "test_expect_code: command exited with $exit_code: $*"
>> + Â Â Â Â Â Â return 0
>
> This makes the tests noisier on success. ÂI have no strong feelings
> either way about that, but it's probably worth mentioning in the commit
> message.
I added a brief note in the commit mesage, which I'll resend with the
fixed-up series in a minute.
--
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