Re: [PATCH] Fixing unclear messages

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 11, 2014, 18:21 UTC
Message-ID: <xmqqha1i7uqn.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAP6f5MmE4ae81DZu-gbaax4nSh4WMcWCk453wJBfC4mKvmsfxA@mail.gmail.com>

Alexander Shopov <ash@kambanaria.org> writes:

Show 7 quoted lines

>>> -                     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.

Show 6 quoted lines

> 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@vger.kernel.org." 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.

Show 6 quoted lines

>>> -             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.