Ilya Bobyr <ilya.bo...@gmail.com> writes:
> Most arguments that could be provided to a test have short forms.
> Unless documented, the only way to learn them is to read the code.
> Signed-off-by: Ilya Bobyr <ilya.bo...@gmail.com>
> t/README | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
> diff --git a/t/README b/t/README
> index caeeb9d..6b93aca 100644
> --- a/t/README
> +++ b/t/README
> @@ -71,7 +71,7 @@ You can pass --verbose (or -v), --debug (or -d), and
> (or -i) command line argument to the test, or by setting GIT_TEST_OPTS
> appropriately before running "make".
> This makes the test more verbose. Specifically, the
> command being run and their output if any are also
I was debating myself if the result should look more like this:
This makes the test more verbose. Specifically, the
command being run and their output if any are also
As a straight text file, your version is certainly a lot easier to
read, but at the same time, the entire file is written in more or
less AsciiDoc format (the list of prerequisites and the list of
harness library functions need to be converted to the "item::" form
for the text to format well, though) and I've seen some efforts by
others to run text files in Documentation/ that were originally
meant to be consumed as straight text thru AsciiDoc, so the latter
form might be a small step for futureproofing.
My conclusion at this point is that the original is good for the
current need of the project; if somebody wants to include this file
from somewhere in Documentation/technical, a conversion to use
multiple "item1::<newline>item2::<newline>description" headers can
be done by that person as part of the "make it fully AsciiDoc"
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html