From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Eugen Konkov <kes-kes@yandex.ru>, Git Mailing List <git@vger.kernel.org>
Subject: Re: Re* --creation-factor=100 does not show code
Date: Fri, 29 Jul 2022 15:19:03 -0700 [thread overview]
Message-ID: <xmqq5yjf4l60.fsf@gitster.g> (raw)
In-Reply-To: <85snn12q-po05-osqs-n1o0-n6040392q01q@tzk.qr> (Johannes Schindelin's message of "Fri, 29 Jul 2022 15:16:12 +0200 (CEST)")
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> As to the original claim that percentages only go from 0-100, that is
> easily refuted. If you wanted to pay $12 for something but ended up having
> to pay $30, you'll end up having paid 150% more than planned. There you
> are. A percentage that is greater than 100.
Playing word games and nitpicks on what I said may have helped you
stroke your ego and annoy other folks (including me) in the
discussion, but unfortunately I do not think it is helping us get
closer to improve either the documentation or behaviour of
range-diff. Now, let's be a bit more constructive and find a way to
unconfuse people like the original reporter?
When we say an option's value is expressed in <percent>, unless we
are careful, people will assume that the valid value the option will
take will lie between 0 and 100, and you cannot blame them. IOW,
while the word "percent" may be 100% correct in your mind, the way
it is used to describe the feature in "git range-diff --help", it
was not sufficient to help readers.
If we were describing a hypothetical Git subcommand that shows a
picture of a panda, with an option to show the picture in different
sizes, perhaps "git panda --scale=<percent>" option is described
like so:
--scale=<percent>::
Instead of showing the picture of a panda at its
default size, show it scaled. "--scale=50" means
show it at 50%, i.e. half the width and height.
"--scale=200" would show the picture at twice the
width and height.
and such a description would make it plenty clear that the valid
value range is not constrainted in 0..100. We'd need something
similar to help users of "git range-diff".
Thanks.
next prev parent reply other threads:[~2022-07-29 22:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-26 12:54 --creation-factor=100 does not show code Eugen Konkov
2022-07-28 14:59 ` Johannes Schindelin
2022-07-28 16:52 ` Re* " Junio C Hamano
2022-07-28 17:12 ` Ævar Arnfjörð Bjarmason
2022-07-28 17:44 ` Junio C Hamano
2022-07-28 19:46 ` Ævar Arnfjörð Bjarmason
2022-07-28 19:54 ` Junio C Hamano
2022-07-28 17:49 ` [PATCH] format-patch: clarify --creation-factor=<factor> Eric Sunshine
2022-07-28 20:55 ` Ævar Arnfjörð Bjarmason
2022-07-28 20:59 ` Junio C Hamano
2022-07-28 21:09 ` Eric Sunshine
2022-07-30 0:25 ` Eric Sunshine
2022-07-31 18:56 ` Junio C Hamano
2022-07-29 13:16 ` Re* --creation-factor=100 does not show code Johannes Schindelin
2022-07-29 22:19 ` Junio C Hamano [this message]
2022-08-01 23:17 ` Junio C Hamano
2023-04-02 21:55 ` Eugen Konkov
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=xmqq5yjf4l60.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=kes-kes@yandex.ru \
/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.