Re: [PATCH] Fixing unclear messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alexander Shopov <ash@xxxxxxxxxxxxxx> writes:

>>> -                     printf_ln(_("Huh (%s)?"), (*ptr)->buf);
>>> +                     printf_ln(_("Wrong choice (%s). Choose again."), (*ptr)->buf);
>> Why is this an improvement?
> Because 'Huh?' without intonation, gesture or a frown provided by a
> human being is hard to understand. It does not state that it is the
> choice the user provided is wrong and does not prompt the user for the
> next action.

This is shown in a human-interactive exchange where a menu has
already given by list_and_choose().  If there were something else
"Huh?" could mean after you give a response to that prompt, but I do
not think there is.

> You say that my change does not tangibly improve on an initially
> unclear and already obsolete message, am I right?

Not really.  This is not obsolete (it is a good trick even in
today's world order), but is not teaching anything new to the user
because it has to be issued too late (and there is no way to give it
before the user realizes it is necessary), so it is not "unclear"
per-se, but it does not help much.  If I were asked to say what it
is then, I would say "it reassures".

I do not strongly oppose its removal, but if we were to remove it,
we shold add a comment to the condition of the previous "if"
statement to remind us why no argument with "only" is allowed if
"amend" is set.

> There was a suggestion to have a separate function that is meant to
> echo messages when there are genuine bugs in Git (impossible cases
> happening, invariants breaking, etc.) This will allow factoring out
> the clause "This is a bug in Git. Please report it to the developers
> with an e-mail to git@xxxxxxxxxxxxxxx." as a single message and I
> prefer that for ease of maintenance.

Yes, I see the primary value of this thread was to trigger that
suggestion to classify which die()s are BUG()s.

>>> -             die(_("Two output directories?"));
>>> +             die(_("Maximum one output directory is allowed."));
>> Why is it an improvement?
> Because the question only implies that the problem is the number of
> directories but says nothing how many directories there should be (0,
> 1, 3... 100?)

Because I've never imagined anybody would sensibly expect "mv a1
a2... dst1 dst2 dst3..." to work (what does that even mean?  Make N
copies of a$m and drop them into each of dst$n?), I never thought of
such a possiblity.  Trying to help more people is good, unless it
needs to be done by bending backwards, and your rewrite here is
definitely a good one in that sense.

> I am not sure what you mean or your objection would be, perhaps I am
> misreading the source of Git.
> ...
> Does this mean the following changes are totally unwelcome or you

FWIW, I see it as a feature to have small number of messages phrased
in colourful ways, especially the ones that do not require reaction
by the users (e.g. "trivial merge succeeded" does not trigger "oops,
I have to ^C and recover immediately") or the required reaction is
obvious (e.g. "you gave me no X and expect me to work?" can only
mean "ah, I have to give X")

We obviously do not want to overdo it, but the ones we have are all
old ones.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]