Mathias Lafeldt <misfire@xxxxxxxxxxx> writes:
> Document all test function arguments in the same way.
>
> While at it, correct some grammatical errors.
>
> Signed-off-by: Mathias Lafeldt <misfire@xxxxxxxxxxx>
Thanks.
> diff --git a/t/README b/t/README
> index 428ee05..e8372d7 100644
> --- a/t/README
> +++ b/t/README
Everything before this hunk looks sensible.
> @@ -503,18 +503,18 @@ library for your script to use.
> test_expect_code 1 git merge "merge msg" B master
> '
>
> - - test_must_fail <git-command>
> + - test_must_fail <command>
> ...
> + Run a command and ensure it fails in a controlled way. Use this
> + instead of "! <command>". When the command dies due to a segfault,
> + test_must_fail diagnoses it as an error; "! <command>" treats it as
> + just another expected failure, which would let such a bug go
> + unnoticed.
>
> - - test_might_fail <git-command>
> + - test_might_fail <command>
>
> Similar to test_must_fail, but tolerate success, too...
But the above two deliberately say "git-command" to clarify that these are
special cases and meant to be used only to run a git command. If we
expect a failure from a command that is not "git", say "date", we would
want to say "! date", not "test_must_fail date".
> @@ -530,7 +530,7 @@ library for your script to use.
> test_path_is_dir <dir> [<diagnosis>]
> test_path_is_missing <path> [<diagnosis>]
>
> - Check whether a file/directory exists or doesn't. <diagnosis> will
> + Check whether a file/directory exists or not. <diagnosis> will
Is the original really a grammo, or is this change just your personal
taste? If I were rewriting this, I would probably say something like:
- test_path_is_file <path> [<diagnosis>]
test_path_is_dir <path> [<diagnosis>]
test_path_is_missing <path> [<diagnosis>]
Check if the named path is a file, if the named path is a
directory, or if the named path does not exist, respectively,
and fail otherwise, showing the <diagnosis> text.
--
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