git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>,
	 git@vger.kernel.org,  Jeff King <peff@peff.net>,
	 Rasmus Villemoes <ravi@prevas.dk>
Subject: Re: [PATCH] git: show alias info only with lone -h
Date: Fri, 25 Jul 2025 16:52:40 -0700	[thread overview]
Message-ID: <xmqqqzy33k1j.fsf@gitster.g> (raw)
In-Reply-To: <a35dc2bf-015c-472d-9528-6763f7aac180@web.de> ("René Scharfe"'s message of "Fri, 25 Jul 2025 20:41:24 +0200")

René Scharfe <l.s.r@web.de> writes:

> Builtin commands show usage information on stdout if called with -h as
> their only option, usage.c::show_usage_if_asked() makes sure of that.
>
> Aliases show alias information on stderr if called with -h as the first
> option since a9a60b94cc (git.c: handle_alias: prepend alias info when
> first argument is -h, 2018-10-09).  This is surprising when using
> aliases for commands that take -h as a normal argument among others,
> like git grep.
>
> Tighten the condition and show the alias information only if -h is the
> only option given, to be consistent with builtins.

Hmph.  This certainly is an obvious improvement, especially when the
alias does not redirect to our commands, e.g. "git g" is an alias to
the system supplied (likely to be GNU) grep:

   $ git -c alias.g='!grep' g -h frotz *.c

which gives us hits in our sources as expected.  But without
arguments, we get the obvious plus something we may not want to see:

   $ git -c alias.g='!grep' g -h
   'g' is aliased to '!grep'
   Usage: grep [OPTION]... PATTERNS [FILE]...
   Try 'grep --help' for more information.

I wonder if we should not run the underlying/aliased command after
showing the alias expansion?  With "grep" we got lucky that a sole
"-h" means the same thing as it means to us (i.e. short help), but
if it is not one of our commands that would not generally hold.  It
is risky to blindly run the external command with a single "-h" as
an argument.

When it redirects to our commands, it is less risky as we aim to
make all our commands honor a single "-h" via t0450.

   $ git -c alias.c=checkout c -h
   'c' is aliased to 'checkout'
   usage: git checkout [<options>] <branch>
      or: git checkout [<options>] [<branch>] -- <file>...

       -b <branch>           create and checkout a new branch
       -B <branch>           create/reset and checkout a branch
   ...
       --pathspec-from-file <file>
                             read pathspec from file
       --pathspec-file-nul   with --pathspec-from-file, pathspec elements are separated with NUL character

But then, it may not be such a good idea to pay attention to "do we
have extra '-h'?" when alias expands to our commands, e.g.

   $ git -c alias.c=checkout c -h main
   usage: git checkout [<options>] <branch>
      or: git checkout [<options>] [<branch>] -- <file>...

       -b <branch>           create and checkout a new branch
       -B <branch>           create/reset and checkout a branch
   ...
       --pathspec-from-file <file>
                             read pathspec from file
       --pathspec-file-nul   with --pathspec-from-file, pathspec elements are separated with NUL character

We get the same short-help, without what alias expansion caused this
mess, and without any indication that we lost 'main' on the command
line.

So, I dunno.

  reply	other threads:[~2025-07-25 23:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-25  8:17 -h prints alias information even for grep Kevin Brodsky
2025-07-25 18:41 ` [PATCH] git: show alias info only with lone -h René Scharfe
2025-07-25 23:52   ` Junio C Hamano [this message]
2025-07-26  8:12     ` Jeff King
2025-07-26 13:12       ` D. Ben Knoble
2025-07-26 14:22         ` D. Ben Knoble
2025-07-29  7:23         ` Jeff King
2025-07-28 13:43       ` Junio C Hamano
2025-07-29  7:26         ` Jeff King

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=xmqqqzy33k1j.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=kevin.brodsky@arm.com \
    --cc=l.s.r@web.de \
    --cc=peff@peff.net \
    --cc=ravi@prevas.dk \
    /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).