git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Git Mailing List" <git@vger.kernel.org>,
	"Martin Ågren" <martin.agren@gmail.com>,
	"Thomas Rikl" <trikl@online.de>,
	"Thomas Gummerer" <t.gummerer@gmail.com>,
	"Jonathan Nieder" <jrnieder@gmail.com>,
	"Jeff King" <peff@peff.net>
Subject: Re: [Alt. PATCH] ls-remote: deprecate -h as short for --heads
Date: Thu, 19 Oct 2017 20:26:47 +0200	[thread overview]
Message-ID: <26112a15-f02c-a910-c8bb-794ca84dc1e5@web.de> (raw)
In-Reply-To: <xmqqk1ztmkbn.fsf@gitster.mtv.corp.google.com>

Am 18.10.2017 um 01:22 schrieb Junio C Hamano:
> René Scharfe <l.s.r@web.de> writes:
> 
>> Stop advertising -h as the short equivalent of --heads, because it's
>> used for showing a short help text for almost all other git commands.
>> Since the ba5f28bf79 (ls-remote: use parse-options api) it has only
>> been working when used together with other parameters anyway.
>>
>> Signed-off-by: Rene Scharfe <l.s.r@web.de>
>> ---
>> That would be step on the way towards more consistent command line
>> switches, in the same vein as d69155119 (t0012: test "-h" with
>> builtins).
> 
> Sorry, but I am not sure whom this and the other approach are trying
> to help.
> 
> The rule we have currently seems to be that "git cmd -h" (no other
> arguments) consistently gives a short help, and if a subcommand
> supports an option "-h" specific to it that is not about giving a
> short help, the caller needs to be aware of it to invoke the option,
> by making sure that there is some other arguments on the command
> line if "-h" form of that subcommand specific option is used, by
> doing e.g. "git ls-remote -h origin" or "git ls-remote --head".
> 
> I can see that this "alternative" approach makes it less convenent
> for folks who have followed that rule by hiding "-h" (with the
> intention of deprecating and possibly removing it in the future) and
> encouraging (and later foring) "--head" to be used instead.
> 
> The other approach burdens new users by changing the rule to "some
> subcommands that have their own '-h' option cannot be asked for a
> brief usage with 'git cmd -h'".  But the thing is, these new users
> who do not know which subcommands do have their own '-h' and which
> ones do not are the ones that benefit most from the consistent "'git
> cmd -h' with no other argument gets short help" rule.

They would help by aligning documentation and code, at a price.  But
of course there is another way to do that -- I just didn't see it the
other day.  We don't have to take anything away:

-- >8 --
Subject: [PATCH] ls-remote: document behavior of lone parameter -h

Reported-by: Thomas Rikl <trikl@online.de>
Analyzed-by: Martin Ågren <martin.agren@gmail.com>
Analyzed-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
---
 Documentation/git-ls-remote.txt | 10 ++++++++++
 builtin/ls-remote.c             |  5 ++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
index 5f2628c8f8..82622e7fbc 100644
--- a/Documentation/git-ls-remote.txt
+++ b/Documentation/git-ls-remote.txt
@@ -29,6 +29,9 @@ OPTIONS
 	These options are _not_ mutually exclusive; when given
 	both, references stored in refs/heads and refs/tags are
 	displayed.
++
+*NOTE*: -h without any other parameters shows a short help text instead
+of any refs.
 
 --refs::
 	Do not show peeled tags or pseudorefs like HEAD	in the output.
@@ -89,6 +92,13 @@ EXAMPLES
 	f25a265a342aed6041ab0cc484224d9ca54b6f41	refs/tags/v0.99.1
 	c5db5456ae3b0873fc659c19fafdde22313cc441	refs/tags/v0.99.2
 	7ceca275d047c90c0c7d5afb13ab97efdf51bd6e	refs/tags/v0.99.3
+	$ git ls-remote -hh
+	From https://git.kernel.org/pub/scm/git/git.git/
+	4c2224e83951a685185bb8c1f83b28e22fee0e27	refs/heads/maint
+	5fe978a5381f1fbad26a80e682ddd2a401966740	refs/heads/master
+	76aedb4517c834be2dc89efb5f9d15908e324422	refs/heads/next
+	c781a84b5204fb294c9ccc79f8b3baceeb32c061	refs/heads/pu
+	5d38b589ccc7a8355c62f1577865df5b8216c00d	refs/heads/todo
 
 GIT
 ---
diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c
index c4be98ab9e..0438dfec05 100644
--- a/builtin/ls-remote.c
+++ b/builtin/ls-remote.c
@@ -56,7 +56,10 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix)
 			   N_("path of git-upload-pack on the remote host"),
 			   PARSE_OPT_HIDDEN },
 		OPT_BIT('t', "tags", &flags, N_("limit to tags"), REF_TAGS),
-		OPT_BIT('h', "heads", &flags, N_("limit to heads"), REF_HEADS),
+		OPT_BIT(0, "heads", &flags, N_("limit to heads"), REF_HEADS),
+		OPT_BIT('h', NULL, &flags,
+			N_("if only parameter: show this help text, otherwise limit to heads"),
+			REF_HEADS),
 		OPT_BIT(0, "refs", &flags, N_("do not show peeled tags"), REF_NORMAL),
 		OPT_BOOL(0, "get-url", &get_url,
 			 N_("take url.<base>.insteadOf into account")),
-- 
2.14.2

  reply	other threads:[~2017-10-19 18:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-15 10:02 Bug: git ls-remote -h / --head results differ in output Thomas Rikl
2017-10-15 11:08 ` Martin Ågren
2017-10-15 13:26   ` René Scharfe
2017-10-17 15:39     ` [PATCH 1/2] git: add NO_INTERNAL_HELP flag for builtins René Scharfe
2017-10-17 17:39       ` Jonathan Nieder
2017-10-17 15:39     ` [PATCH 2/2] ls-remote: use PARSE_OPT_NO_INTERNAL_HELP René Scharfe
2017-10-17 17:42       ` Jonathan Nieder
2017-10-17 17:42       ` Martin Ågren
2017-10-17 15:39     ` [Alt. PATCH] ls-remote: deprecate -h as short for --heads René Scharfe
2017-10-17 17:40       ` Martin Ågren
2017-10-17 17:43       ` Jonathan Nieder
2017-10-17 23:22       ` Junio C Hamano
2017-10-19 18:26         ` René Scharfe [this message]
2017-10-19 20:32           ` Jeff King
2017-10-20  1:04             ` Junio C Hamano
2017-10-20  3:05               ` Jeff King
2017-10-20  5:35                 ` Junio C Hamano
2017-10-21  7:16                   ` Jeff King
2017-10-21 10:14                   ` René Scharfe
2017-10-21 12:18                     ` Junio C Hamano
2017-10-23 15:05                       ` René Scharfe
2017-10-24  0:52                         ` Junio C Hamano
2017-10-24 18:26                           ` René Scharfe

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26112a15-f02c-a910-c8bb-794ca84dc1e5@web.de \
    --to=l.s.r@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=martin.agren@gmail.com \
    --cc=peff@peff.net \
    --cc=t.gummerer@gmail.com \
    --cc=trikl@online.de \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).