All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jari Aalto <jari.aalto@cante.net>, git@vger.kernel.org
Subject: Re: [PATCH] git-rebase.sh: Update USAGE string (No. 1)
Date: Mon, 4 Feb 2008 11:15:20 +0100	[thread overview]
Message-ID: <200802041115.22409.jnareb@gmail.com> (raw)
In-Reply-To: <7vfxw9pnbp.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:
> Jari Aalto <jari.aalto@cante.net> writes:
> 
>> * Sun 2008-02-03 Jakub Narebski <jnareb@gmail.com> INBOX
>>> I would say "[--whitespace=<option>]" or "[--whitespace=<action>]"
>>> instead of introducing yet not agreed upon notation (this has the
>>> advantage of shortening synopisis, which should be short IMHO).
>>
>> The "{a|b|c}" is a used syntax. See cpio(1).
>>  
>>     cpio  {-o|--create} [-0acvABLV] ...

BTW. it is not only cpio and rpm, but also combinediff (and friends from 
patchutils), flex, gimp, jpegtopnm (and other from netpbm), ps2pdf, 
run, tail, xmlto, ip, losetup, netstat, sudo and sudoedit,...

> I do not think using {} for grouping is incorrect, and I think
> there is at least a consensus on the list that it is Ok as long
> as we consistently do so.
> 
> Unfortunately, the majority of, if not all of, our existing
> documents use () instead for that purpose.
> 
> So pros-and-cons are that (1) changing all of them to use {} is
> more politically correct (pro); (2) our use of (), as we
> consistently use them, does not hurt readability (neutral); and

Actually we are not entirely consistent here.  git-init(1) has 
  --shared[={false|true|umask|group|all|world|everybody}]
in the option description, git-rev-list(1) has
  [ --date={local|relative|default|iso|rfc|short} ]
in its longish synopsis (although in second case we could omit
the curlies, it is in separate line so reducing line length does
not matter in this case).

> (3) it is a thankless makework to replace them all to {} _and
> make sure the conversion is correct_ (large con).  

All true.

> (4) also if 
> other people make changes to documentation at the same time,
> that would add more work in conflict resolution (slight con).

Well, we sould have to document this in CodingStyle, I think, then.
 
> About the part your patch touches, [--whitespace={a|b|c}] is
> more precise than [--whitespace=a|b|c] Jakub suggested, but I
> suspect most sane people would not misinterpret the latter as
> "this part can be omitted but you could write '--whitespace=a',
> 'b' or 'c' here", so...

It probably also depends if we deperately want to reduce line length as 
not to split synopsis into yet another line (the shorter synopsis is, 
usually the better).

-- 
Jakub Narebski
Poland

  reply	other threads:[~2008-02-04 10:16 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-03 20:19 [PATCH] git-rebase.sh: Update USAGE string Jari Aalto
2008-02-03 21:14 ` Jakub Narebski
2008-02-03 23:33 ` [PATCH] git-rebase.sh: Update USAGE string (No. 1) Jari Aalto
2008-02-03 23:41   ` Johannes Schindelin
2008-02-03 23:52   ` Jakub Narebski
2008-02-04  0:11     ` Jari Aalto
2008-02-04  0:27       ` Johannes Schindelin
2008-02-04  0:39       ` Junio C Hamano
2008-02-04 10:15         ` Jakub Narebski [this message]
2008-02-04 11:57           ` Mike Hommey
2008-02-04 12:53             ` Jakub Narebski
2008-02-04  0:24     ` Junio C Hamano
2008-02-04  8:04       ` [PATCH v3] git-rebase.sh: Update USAGE string Jari Aalto
2008-02-04 11:12     ` [PATCH] git-rebase.sh: Update USAGE string (No. 1) しらいしななこ
2008-02-04 15:06       ` rebase -i and --whitespace, was " Johannes Schindelin
2008-02-04 15:42         ` Jakub Narebski
2008-02-04 16:32           ` Johannes Schindelin
2008-02-05 23:43           ` Junio C Hamano
2008-02-06  1:00             ` Johannes Schindelin
2008-02-04  0:16 ` [PATCH v2] git-rebase.sh: Update USAGE string Jari Aalto

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=200802041115.22409.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jari.aalto@cante.net \
    /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.