Re: [PATCH] Documentation: add a script to generate a (long/short) options overview

2013-10-31 Thread brian m. carlson
On Fri, Nov 01, 2013 at 12:09:10AM +0100, Stefan Beller wrote:
 On 11/01/2013 12:04 AM, Stefan Beller wrote:
  Recently a discussion started on the mailing list, which short option
  shall be best for a long option. (-f being always --force and therefore
  should not be reassigned another meaning in one particular command)
  See http://www.mail-archive.com/git@vger.kernel.org/msg38456.html
  
  For discussions as these we need a script to easily generate an
  overview of all available one letter options, and their long option
  equivalents.
  
  As the list of options was not retrieved fully automated,
  there might be minor errors or missing items.
  
  Signed-off-by: Stefan Beller stefanbel...@googlemail.com
  ---
   Documentation/generateShortOptions.py | 460 
  ++
   1 file changed, 460 insertions(+)
   create mode 100644 Documentation/generateShortOptions.py
  
 
 When trying to send a follow-up patch with the table itself, I got:
 fatal: 
 /tmp/wHpJlnf1r5/0002-Documentation-add-table-viewing-short-long-options-f.patch:
  19: patch contains a line longer than 998 characters
 warning: no patches were sent
 
 Is this an artifical limitation or something that actually makes sense?

RFC 5321 forbids lines exceeding 1000 octets (including CRLF).  RFC 5322
forbids lines exceeding 998 characters (excluding CRLF).  If you want to
get around that, you need to base64-encode the content, which is
generally discouraged when sending patches, I believe.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature


Re: [PATCH] Documentation: add a script to generate a (long/short) options overview

2013-10-31 Thread Junio C Hamano
brian m. carlson sand...@crustytoothpaste.net writes:

 RFC 5321 forbids lines exceeding 1000 octets (including CRLF).  RFC 5322
 forbids lines exceeding 998 characters (excluding CRLF).  If you want to
 get around that, you need to base64-encode the content, which is
 generally discouraged when sending patches, I believe.

All true.

A message like the one posted before and got a positive wow, good
work, is a good thinkg to motivate somebody to work on bringing the
codebase and build procedure to aspire for producing that table from
within the build procedure; I do not think this information fixed in
time belongs to the source tree (iow, making it into a patch form is
of no use).  It will go stale over time without a way to automate
the synchronization somehow.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html