Re: [PATCH v2] submodule: port subcommand 'set-branch' from shell to C

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

 



Kaartic Sivaraam <kaartic.sivaraam@xxxxxxxxx> writes:

> Hi Shourya,
>
> On 20-05-2020 17:45, Shourya Shukla wrote:
>> On 19/05 02:57, Eric Sunshine wrote:
>>> On Tue, May 19, 2020 at 2:27 PM Shourya Shukla
>>> <shouryashukla.oo@xxxxxxxxx> wrote:
>>>> +       if (opt_branch && opt_default)
>>>> +               die(_("--branch and --default do not make sense together"));
>>>
>>> A more precise way to say this is:
>>>
>>>      die(_("--branch and --default are mutually exclusive"));
>>
>> Will that be clear to everyone? What I mean is maybe a person from a
>> non-mathematical background (someone doing programming as a hobby maybe)
>> will not grasp at this at one go and will have to search it's meaning
>> online. Isn't it fine as-is?
>>
>
> While "mutually exclusive" might be prominently used in mathematics. I
> don't think it is only understandable by people with a mathematical
> background.
>
> Moreover, I see 183 results in 36 files for "mutually exclusive" in
> git.git (including translation files). So, this isn't anything new.
>
> I agree with Eric's suggestion. It makes the error message concise
> which is a nice side benefit.

Sure.  

But "do not make sense together" is forcing the reader to infer the
implication "... hence cannot use at the same time", so it is one
step detached from what we really want them to know, while giving
half an explanation (it still invites "why don't they make sense
together?") so why not say that conclusion more directly?  i.e.
"... cannot be used together"?  Either way those who need to be told
more would ask "why can't I use them together?" anyway, so half an
explanation would not help all that much.





[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]

  Powered by Linux