git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Francesco Occhipinti <Francesco.Occhipinti@tracsis.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: New checkout --track behaviour?
Date: Fri, 13 Dec 2024 19:39:15 +0900	[thread overview]
Message-ID: <xmqqed2beujw.fsf@gitster.g> (raw)
In-Reply-To: <Z1uuqKI_2rb0HXhP@tapette.crustytoothpaste.net> (brian m. carlson's message of "Fri, 13 Dec 2024 03:48:56 +0000")

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> This is indeed a subtle incompatibility in command-line option parsing,
> but it's not really avoidable and it does occur in pretty much any case
> where a short option learns to take an optional argument (for any
> software, not just Git).

Perhaps we'd want something along this line?  While it is not really
avoidable if we have to add an optional value to an existing option,
"not really avoidable" is not a very satisfactory explanation to
please those whose established use cases they have, or their
scripts, have got broken.

--- >8 ------ >8 ------ >8 ---
Subject: gitcli: explain why short options are better spelled separately

When the "--track" option of "git checkout" command learned to take
an optional value a few years ago at d3115660 (branch: add flags and
config to inherit tracking, 2021-12-20), "git checkout -tb foo" got
broken, as it is no longer two options "--track" and "--branch=foo"
given together, but "--track=b" and a regular argument "foo".  The
command parser dies upon seeing "-tb" saying "b" is not a valid
optional value to "-t".

We already discourage users to spell short options in stuck form,
and if they spelled "-t -b foo", they would not have noticed this
breakage.  Add a bit more words to "git help cli" to explain why
we discourage the stuck form.

We might also want to add a note to ourselves (perhaps next to the
Documentation/CodingGuidelines, we'd want design guidelines) to
think very carefully before considering to introduce an option that
takes an optional value, and refrain from adding an optional value
to an existing option.  It would save the end users from confusion.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/gitcli.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git c/Documentation/gitcli.txt w/Documentation/gitcli.txt
index bd62cbd043..dcc0aa5bf7 100644
--- c/Documentation/gitcli.txt
+++ w/Documentation/gitcli.txt
@@ -82,7 +82,9 @@ Here are the rules regarding the "flags" that you should follow when you are
 scripting Git:
 
  * Splitting short options to separate words (prefer `git foo -a -b`
-   to `git foo -ab`, the latter may not even work).
+   to `git foo -ab`, the latter may not even work, and even if it
+   worked, it will change the meaning once the '-a' option starts
+   taking an optional value).
 
  * When a command-line option takes an argument, use the 'stuck' form.  In
    other words, write `git foo -oArg` instead of `git foo -o Arg` for short

  reply	other threads:[~2024-12-13 10:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <DB9PR08MB7194822B81F17420B2D3C149903F2@DB9PR08MB7194.eurprd08.prod.outlook.com>
2024-12-12 10:29 ` New checkout --track behaviour? Francesco Occhipinti
2024-12-13  3:48   ` brian m. carlson
2024-12-13 10:39     ` Junio C Hamano [this message]
2024-12-13 10:50     ` Francesco Occhipinti

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=xmqqed2beujw.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=Francesco.Occhipinti@tracsis.com \
    --cc=git@vger.kernel.org \
    --cc=sandals@crustytoothpaste.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 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).