From: Junio C Hamano <gitster@pobox.com>
To: Ilya Bobyr <ilya.bobyr@gmail.com>
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>,
git@vger.kernel.org, Thomas Rast <trast@inf.ethz.ch>,
Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH 1/3] test-lib: Document short options in t/README
Date: Tue, 25 Mar 2014 10:23:38 -0700 [thread overview]
Message-ID: <xmqqior2mbtx.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <53306910.3090807@gmail.com> (Ilya Bobyr's message of "Mon, 24 Mar 2014 10:19:12 -0700")
Ilya Bobyr <ilya.bobyr@gmail.com> writes:
> On 3/24/2014 4:39 AM, Ramsay Jones wrote:
>> On 24/03/14 08:49, Ilya Bobyr wrote:
>>> Most arguments that could be provided to a test have short forms.
>>> Unless documented the only way to learn then is to read the code.
>>>
>>> Signed-off-by: Ilya Bobyr <ilya.bobyr@gmail.com>
>>> ---
>>> t/README | 10 +++++-----
>>> 1 files changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/t/README b/t/README
>>> index caeeb9d..ccb5989 100644
>>> --- a/t/README
>>> +++ b/t/README
>>> @@ -71,7 +71,7 @@ You can pass --verbose (or -v), --debug (or -d), and --immediate
>>> (or -i) command line argument to the test, or by setting GIT_TEST_OPTS
>>> appropriately before running "make".
>>>
>>> ---verbose::
>>> +-v,--verbose::
>> OK
>>
>>> [...]
>>>
>>> ---valgrind=<tool>::
>>> +-v,--valgrind=<tool>::
>> The -v short option is taken, above ... :-P
>
> Right %)
> Thanks :)
> This one starts only with "--va", will fix it.
Please don't.
In general, when option names can be shortened by taking a unique
prefix, it is better not to give short form in the documentation at
all. There is no guarantee that the short form you happen to pick
when you document it will continue to be unique forever. When we
add another --vasomething option, --va will become ambiguous and one
of these two things must happen:
(1) --valgrind and --vasomething are equally useful and often used.
Neither will get --va and either --val or --vas needs to be
given.
(2) Because we documented --va as --valgrind, people feel that they
are entitled to expect --va will stay forever to be a shorthand
for --valgrind and nothing else. The shortened forms will be
between --va (or longer prefix of --valgrind) and --vas (or
longer prefix of --vasomething).
We would rather want to see (1), as people new to the system do not
have to learn that --valgrind can be spelled --va merely by being
the first to appear, and --vasomething must be spelled --vas because
it happened to come later. Longer term, nobody should care how the
system evolved into the current shape, but (2) will require that to
understand and remember why one is --va and the other has to be --vas.
We already have this suboptimal (2) situation between "--valgrind"
and "--verbose" options, but a shorter form "v" that is used for
"verbose" is so widely understood and used that I think it is an
acceptable exception. So
--verbose::
+-v::
Give verbose output from the test
is OK, but "--valgrind can be shortened to --va" is not.
next prev parent reply other threads:[~2014-03-25 17:25 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-24 8:49 [RFC/PATCH] Better control of the tests run by a test suite Ilya Bobyr
2014-03-24 8:49 ` [PATCH 1/3] test-lib: Document short options in t/README Ilya Bobyr
2014-03-24 11:39 ` Ramsay Jones
2014-03-24 17:19 ` Ilya Bobyr
2014-03-25 17:23 ` Junio C Hamano [this message]
2014-03-27 9:39 ` Ilya Bobyr
2014-03-27 16:35 ` Junio C Hamano
2014-03-28 17:20 ` Junio C Hamano
2014-03-25 5:52 ` Eric Sunshine
2014-03-24 8:49 ` [PATCH 2/3] test-lib: tests skipped by GIT_SKIP_TESTS say so Ilya Bobyr
2014-03-24 8:49 ` [PATCH 3/3] test-lib: '--run' to run only specific tests Ilya Bobyr
2014-03-24 23:03 ` [RFC/PATCH] Better control of the tests run by a test suite Jeff King
2014-03-25 4:58 ` Junio C Hamano
2014-03-27 10:15 ` Ilya Bobyr
2014-03-27 10:32 ` [RFC/PATCH v2] " Ilya Bobyr
2014-03-27 10:32 ` [PATCH 1/3] test-lib: Document short options in t/README Ilya Bobyr
2014-03-27 10:32 ` [PATCH 2/3] test-lib: tests skipped by GIT_SKIP_TESTS say so Ilya Bobyr
2014-03-27 10:32 ` [PATCH 3/3] test-lib: '--run' to run only specific tests Ilya Bobyr
2014-03-28 3:36 ` Eric Sunshine
2014-03-28 7:05 ` Ilya Bobyr
2014-03-30 9:41 ` Eric Sunshine
2014-03-31 17:09 ` Junio C Hamano
2014-03-31 19:35 ` David Tran
-- strict thread matches above, loose matches on Subject: below --
2014-04-22 8:19 [RFC/PATCH v3] Better control of the tests run by a test suite Ilya Bobyr
2014-04-22 8:19 ` [PATCH 1/3] test-lib: Document short options in t/README Ilya Bobyr
2014-04-23 18:24 ` Junio C Hamano
2014-04-30 9:38 ` Ilya Bobyr
2014-04-30 9:50 ` [RFC/PATCH v4] Better control of the tests run by a test suite Ilya Bobyr
2014-04-30 9:50 ` [PATCH 1/3] test-lib: Document short options in t/README Ilya Bobyr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqior2mbtx.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ilya.bobyr@gmail.com \
--cc=ramsay@ramsay1.demon.co.uk \
--cc=sunshine@sunshineco.com \
--cc=trast@inf.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.