git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Git Mailing List <git@vger.kernel.org>
Subject: [1.8.0 RFD] Homogeneous use of short options
Date: Mon, 14 Feb 2011 16:04:00 +0100	[thread overview]
Message-ID: <4D594460.1040206@drmicha.warpmail.net> (raw)

Proposal:
Make our use of short options more homogeneous.

I have put together a list of options which are used by the "most common
commands", using the output of "git --help-all":

http://repo.or.cz/w/git/mjg.git/blob/options.txt

(scroll down for the short options)

This leaves out a few commands with different option parsing (diff, log,
rebase, show) but indicates that we're doing a good job already. A few
notable outliers:

add -A: Why capital A? Compare commit -a etc.

commit -n, fetch -n, merge -n: These are REALLY bad! Users should be
able to rely on '-n' being '--dry-run' or at least being no-op to their
repo, like clone/grep/tag -n.

tag -v: This is not a real problem, but users have certain expections
for "-f,-h,-n,-v" which we should break as rarely as possible. OTOH,
what would "verbose" mean for tag? (NB: tag.txt is grossly wrong.)

grep -?: This tries to be compatible with GNU grep, so it's a natural
outlier.

Risks:
Users and scripts may obviously depend on the current options names.

Migration plan:
Introduce new options first (1.7.x) along with warnings in the release
notes (optionally, make the commands output warnings). Then change the
behavior in 1.8.0.

TODO:
Generate an option list for the other common commands.

I'll also follow up with a little series fixing inconsistencies in the
descriptions.

             reply	other threads:[~2011-02-14 15:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-14 15:04 Michael J Gruber [this message]
2011-02-14 15:19 ` [1.8.0 RFD] Homogeneous use of short options Nguyen Thai Ngoc Duy
2011-02-14 19:03 ` Jay Soffian
2011-02-14 21:00 ` Junio C Hamano
2011-02-15  0:52   ` Miles Bader
2011-02-15  7:18     ` Michael J Gruber

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=4D594460.1040206@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).