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@xxxxxxxxxxxxxxx/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 <stefanbeller@xxxxxxxxxxxxxx> > > --- > > 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
Attachment:
signature.asc
Description: Digital signature