{"thread":{"id":"63846","subject":"-h prints alias information even for grep","startedAt":"2025-07-25T08:17:48Z","lastAt":"2025-07-29T07:26:51Z","messageCount":9,"participants":["Kevin Brodsky","René Scharfe","Junio C Hamano","Jeff King","D. Ben Knoble"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"522734","messageId":"1c3a0463-36ee-4a2d-92e0-fac9c0bf77da@arm.com","threadId":"63846","inReplyTo":null,"subject":"-h prints alias information even for grep","fromName":"Kevin Brodsky","fromEmail":"kevin.brodsky@arm.com","sentAt":"2025-07-25T08:17:43Z","receivedAt":"2025-07-25T08:17:48Z","isPatch":false,"sender":{"key":"kevin.brodsky@arm.com","avatar":null},"body":"Hi,\n\nI've noticed a strange interaction that probably wasn't intended.\n\nThe -h flag typically means \"help\", and if passed to an aliased command\nan extra line is printed to describe the alias. This also holds for the\ngrep command, if no other argument is passed.\n\nThings get weirder if grep is passed valid arguments, because in that\ncase -h means something else (suppressing filename output). Of course no\nhelp message is printed in that case, but the alias information is still\nprinted!\n\nExample:\n\n$ git g -h -A20 alias .gitconfig\n'g' is aliased to 'grep'\n[alias]\n[...]\n    g    = grep\n\n----\n\nIt seems like that alias information line should be tied to the printing\nof the help message, rather than the -h flag?\n\nI noticed this behaviour years ago and I still do with the latest\nversion of Git (2.50.1).\n\nCheers,\nKevin\n"},{"id":"522764","messageId":"a35dc2bf-015c-472d-9528-6763f7aac180@web.de","threadId":"63846","inReplyTo":"1c3a0463-36ee-4a2d-92e0-fac9c0bf77da@arm.com","subject":"[PATCH] git: show alias info only with lone -h","fromName":"René Scharfe","fromEmail":"l.s.r@web.de","sentAt":"2025-07-25T18:41:24Z","receivedAt":"2025-07-25T18:41:39Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Builtin commands show usage information on stdout if called with -h as\ntheir only option, usage.c::show_usage_if_asked() makes sure of that.\n\nAliases show alias information on stderr if called with -h as the first\noption since a9a60b94cc (git.c: handle_alias: prepend alias info when\nfirst argument is -h, 2018-10-09). This is surprising when using\naliases for commands that take -h as a normal argument among others,\nlike git grep.\n\nTighten the condition and show the alias information only if -h is the\nonly option given, to be consistent with builtins.\n\nIt's probably still is a good idea to write to stderr, as an alias\ncommand doesn't have to be a builtin and could instead produce output\nwith just -h that might be spoiled by an extra alias info line.\n\nReported-by: Kevin Brodsky \nSigned-off-by: René Scharfe \n---\n git.c | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/git.c b/git.c\nindex 07a5fe39fb..83eac0aeab 100644\n--- a/git.c\n+++ b/git.c\n@@ -371,7 +371,7 @@ static int handle_alias(struct strvec *args)\n \talias_command = args->v[0];\n \talias_string = alias_lookup(alias_command);\n \tif (alias_string) {\n-\t\tif (args->nr > 1 && !strcmp(args->v[1], \"-h\"))\n+\t\tif (args->nr == 2 && !strcmp(args->v[1], \"-h\"))\n \t\t\tfprintf_ln(stderr, _(\"'%s' is aliased to '%s'\"),\n \t\t\t\t alias_command, alias_string);\n \t\tif (alias_string[0] == '!') {\n-- \n2.50.1\n"},{"id":"522775","messageId":"xmqqqzy33k1j.fsf@gitster.g","threadId":"63846","inReplyTo":"a35dc2bf-015c-472d-9528-6763f7aac180@web.de","subject":"Re: [PATCH] git: show alias info only with lone -h","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-25T23:52:40Z","receivedAt":"2025-07-25T23:52:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe writes:\n\n> Builtin commands show usage information on stdout if called with -h as\n> their only option, usage.c::show_usage_if_asked() makes sure of that.\n>\n> Aliases show alias information on stderr if called with -h as the first\n> option since a9a60b94cc (git.c: handle_alias: prepend alias info when\n> first argument is -h, 2018-10-09). This is surprising when using\n> aliases for commands that take -h as a normal argument among others,\n> like git grep.\n>\n> Tighten the condition and show the alias information only if -h is the\n> only option given, to be consistent with builtins.\n\nHmph. This certainly is an obvious improvement, especially when the\nalias does not redirect to our commands, e.g. \"git g\" is an alias to\nthe system supplied (likely to be GNU) grep:\n\n $ git -c alias.g='!grep' g -h frotz *.c\n\nwhich gives us hits in our sources as expected. But without\narguments, we get the obvious plus something we may not want to see:\n\n $ git -c alias.g='!grep' g -h\n 'g' is aliased to '!grep'\n Usage: grep [OPTION]... PATTERNS [FILE]...\n Try 'grep --help' for more information.\n\nI wonder if we should not run the underlying/aliased command after\nshowing the alias expansion? With \"grep\" we got lucky that a sole\n\"-h\" means the same thing as it means to us (i.e. short help), but\nif it is not one of our commands that would not generally hold. It\nis risky to blindly run the external command with a single \"-h\" as\nan argument.\n\nWhen it redirects to our commands, it is less risky as we aim to\nmake all our commands honor a single \"-h\" via t0450.\n\n $ git -c alias.c=checkout c -h\n 'c' is aliased to 'checkout'\n usage: git checkout [] \n or: git checkout [] [] -- ...\n\n -b create and checkout a new branch\n -B create/reset and checkout a branch\n ...\n --pathspec-from-file \n read pathspec from file\n --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character\n\nBut then, it may not be such a good idea to pay attention to \"do we\nhave extra '-h'?\" when alias expands to our commands, e.g.\n\n $ git -c alias.c=checkout c -h main\n usage: git checkout [] \n or: git checkout [] [] -- ...\n\n -b create and checkout a new branch\n -B create/reset and checkout a branch\n ...\n --pathspec-from-file \n read pathspec from file\n --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character\n\nWe get the same short-help, without what alias expansion caused this\nmess, and without any indication that we lost 'main' on the command\nline.\n\nSo, I dunno.\n"},{"id":"522785","messageId":"20250726081254.GA3042329@coredump.intra.peff.net","threadId":"63846","inReplyTo":"xmqqqzy33k1j.fsf@gitster.g","subject":"Re: [PATCH] git: show alias info only with lone -h","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-07-26T08:12:54Z","receivedAt":"2025-07-26T08:12:55Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jul 25, 2025 at 04:52:40PM -0700, Junio C Hamano wrote:\n\n> When it redirects to our commands, it is less risky as we aim to\n> make all our commands honor a single \"-h\" via t0450.\n> \n> $ git -c alias.c=checkout c -h\n> 'c' is aliased to 'checkout'\n> usage: git checkout [] \n> or: git checkout [] [] -- ...\n> \n> -b create and checkout a new branch\n> -B create/reset and checkout a branch\n> ...\n> --pathspec-from-file \n> read pathspec from file\n> --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character\n> \n> But then, it may not be such a good idea to pay attention to \"do we\n> have extra '-h'?\" when alias expands to our commands, e.g.\n\nAnother interesting case: even for our own commands, the alias itself\nmay add extra arguments, which confuses things further. So:\n\n $ git -c alias.gi='grep --cached' gi -h\n 'gi' is aliased to 'grep --cached'\n fatal: no pattern given\n\nruns git-grep, but even though the user said only \"-h\" the alias added\nanother option which prevents the help-mode from activating.\n\nIn this case it is not too harmful, but you can come up with\npathological cases where it actually runs a real command:\n\n git -c alias.grep-for-foo='grep -e foo' grep-for-foo -h\n\nwhich runs a real grep.\n\nI guess one way to deal with it would be if the user runs \"foo -h\", and\nalias.foo is \"bar --other arguments\", then we run just \"bar -h\",\ndropping the extra arguments provided by the alias.\n\n(Another fun corner case: not all git-foo are our commands. But maybe it\nis enough to say \"if you make a third-party git-foo it should probably\nrespect bare -h as an option\").\n\n> $ git -c alias.c=checkout c -h main\n> usage: git checkout [] \n> or: git checkout [] [] -- ...\n> \n> -b create and checkout a new branch\n> -B create/reset and checkout a branch\n> ...\n> --pathspec-from-file \n> read pathspec from file\n> --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character\n> \n> We get the same short-help, without what alias expansion caused this\n> mess, and without any indication that we lost 'main' on the command\n> line.\n\nYeah, that is the flip side of René's patch. Right now we overly guess\nthat \"-h\" means help. And after the patch, we'd sometimes under-guess\nthat it meant help, even for commands which treat it as such. I think\nthat may be the lesser of two evils, though; if you are asking for help\nthen \"git c -h\" is the most-strict way to do it.\n\nSo IMHO the patch under discussion is a strict improvement, even though\nit leaves many other questionable cases unsolved. I'd also be happy if\non top we did:\n\n 1. When alias.foo=\"bar --options\", turn \"git foo -h\" into \"git bar\n -h\", dropping \"--options\".\n\n 2. When alias.foo=\"!bar\", report only the alias and do not run \"bar\"\n at all. The collateral damage here would be:\n\n !git bar $(some_shell_magic_we_need)\n\n but IMHO that is not all that bad. If we report the alias content,\n the user can probably figure out which \"git help\" to run next.\n\n-Peff\n"},{"id":"522788","messageId":"CALnO6CA2qSYePJzqXjdW6c2zC4KQJSKzsCFCzc9si0OJ8E_ohw@mail.gmail.com","threadId":"63846","inReplyTo":"20250726081254.GA3042329@coredump.intra.peff.net","subject":"Re: [PATCH] git: show alias info only with lone -h","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-07-26T13:12:55Z","receivedAt":"2025-07-26T13:13:08Z","isPatch":true,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"I have a few (unsent) patches I've been working on that touch the help\nmechanism, so I have some thoughts below.\n\nOn Sat, Jul 26, 2025 at 4:13 AM Jeff King wrote:\n>\n> On Fri, Jul 25, 2025 at 04:52:40PM -0700, Junio C Hamano wrote:\n>\n> > When it redirects to our commands, it is less risky as we aim to\n> > make all our commands honor a single \"-h\" via t0450.\n> >\n> > $ git -c alias.c=checkout c -h\n> > 'c' is aliased to 'checkout'\n> > usage: git checkout [] \n> > or: git checkout [] [] -- ...\n> >\n> > -b create and checkout a new branch\n> > -B create/reset and checkout a branch\n> > ...\n> > --pathspec-from-file \n> > read pathspec from file\n> > --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character\n> >\n> > But then, it may not be such a good idea to pay attention to \"do we\n> > have extra '-h'?\" when alias expands to our commands, e.g.\n>\n> Another interesting case: even for our own commands, the alias itself\n> may add extra arguments, which confuses things further. So:\n>\n> $ git -c alias.gi='grep --cached' gi -h\n> 'gi' is aliased to 'grep --cached'\n> fatal: no pattern given\n>\n> runs git-grep, but even though the user said only \"-h\" the alias added\n> another option which prevents the help-mode from activating.\n>\n> In this case it is not too harmful, but you can come up with\n> pathological cases where it actually runs a real command:\n>\n> git -c alias.grep-for-foo='grep -e foo' grep-for-foo -h\n>\n> which runs a real grep.\n>\n> I guess one way to deal with it would be if the user runs \"foo -h\", and\n> alias.foo is \"bar --other arguments\", then we run just \"bar -h\",\n> dropping the extra arguments provided by the alias.\n\nThis is intriguing: it would mean that an alias is not purely a\ntextual replacement? That's true for ! aliases today, but other than\nshelling out it's pretty close.\n\n>\n> (Another fun corner case: not all git-foo are our commands. But maybe it\n> is enough to say \"if you make a third-party git-foo it should probably\n> respect bare -h as an option\").\n>\n> > $ git -c alias.c=checkout c -h main\n> > usage: git checkout [] \n> > or: git checkout [] [] -- ...\n> >\n> > -b create and checkout a new branch\n> > -B create/reset and checkout a branch\n> > ...\n> > --pathspec-from-file \n> > read pathspec from file\n> > --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character\n> >\n> > We get the same short-help, without what alias expansion caused this\n> > mess, and without any indication that we lost 'main' on the command\n> > line.\n>\n> Yeah, that is the flip side of René's patch. Right now we overly guess\n> that \"-h\" means help. And after the patch, we'd sometimes under-guess\n> that it meant help, even for commands which treat it as such. I think\n> that may be the lesser of two evils, though; if you are asking for help\n> then \"git c -h\" is the most-strict way to do it.\n>\n> So IMHO the patch under discussion is a strict improvement, even though\n> it leaves many other questionable cases unsolved. I'd also be happy if\n> on top we did:\n>\n> 1. When alias.foo=\"bar --options\", turn \"git foo -h\" into \"git bar\n> -h\", dropping \"--options\".\n>\n> 2. When alias.foo=\"!bar\", report only the alias and do not run \"bar\"\n> at all. The collateral damage here would be:\n>\n> !git bar $(some_shell_magic_we_need)\n>\n> but IMHO that is not all that bad. If we report the alias content,\n> the user can probably figure out which \"git help\" to run next.\n\nAnd if the user actually wanted to run `bar -h`, say, because `-h`\ndidn't mean help for that command? I can't come up with a compelling\nexample, but this goes back to \"textual substitution\" vs. \"trying to\ndecide what the user actually wants.\"\n\nAt any rate, a (3) to consider is \"--help-all\": the patches I've been\nworking on are to make that flag work more often outside of Git\nrepositories. I just need to clean things up a bit and get to tests.\nBut if we do treat \"git alias -h\" specially, perhaps \"--help-all\" then\nalso warrants treatment.\n\n>\n> -Peff\n>\n\n\n-- \nD. Ben Knoble\n"},{"id":"522793","messageId":"CALnO6CCcYfzHUif=qQHxODnj_kGvGrYYV==4gJKWwxcKS+2JBA@mail.gmail.com","threadId":"63846","inReplyTo":"CALnO6CA2qSYePJzqXjdW6c2zC4KQJSKzsCFCzc9si0OJ8E_ohw@mail.gmail.com","subject":"Re: [PATCH] git: show alias info only with lone -h","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-07-26T14:22:38Z","receivedAt":"2025-07-26T14:22:51Z","isPatch":true,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Sat, Jul 26, 2025 at 9:12 AM D. Ben Knoble wrote:\n>\n> I have a few (unsent) patches I've been working on that touch the help\n> mechanism, so I have some thoughts below.\n>\n> On Sat, Jul 26, 2025 at 4:13 AM Jeff King wrote:\n> >\n> > On Fri, Jul 25, 2025 at 04:52:40PM -0700, Junio C Hamano wrote:\n> >\n> > > When it redirects to our commands, it is less risky as we aim to\n> > > make all our commands honor a single \"-h\" via t0450.\n> > >\n> > > $ git -c alias.c=checkout c -h\n> > > 'c' is aliased to 'checkout'\n> > > usage: git checkout [] \n> > > or: git checkout [] [] -- ...\n> > >\n> > > -b create and checkout a new branch\n> > > -B create/reset and checkout a branch\n> > > ...\n> > > --pathspec-from-file \n> > > read pathspec from file\n> > > --pathspec-file-nul with --pathspec-from-file, pathspec elements are separated with NUL character\n> > >\n> > > But then, it may not be such a good idea to pay attention to \"do we\n> > > have extra '-h'?\" when alias expands to our commands, e.g.\n> >\n> > Another interesting case: even for our own commands, the alias itself\n> > may add extra arguments, which confuses things further. So:\n> >\n> > $ git -c alias.gi='grep --cached' gi -h\n> > 'gi' is aliased to 'grep --cached'\n> > fatal: no pattern given\n> >\n> > runs git-grep, but even though the user said only \"-h\" the alias added\n> > another option which prevents the help-mode from activating.\n> >\n> > In this case it is not too harmful, but you can come up with\n> > pathological cases where it actually runs a real command:\n> >\n> > git -c alias.grep-for-foo='grep -e foo' grep-for-foo -h\n> >\n> > which runs a real grep.\n> >\n> > I guess one way to deal with it would be if the user runs \"foo -h\", and\n> > alias.foo is \"bar --other arguments\", then we run just \"bar -h\",\n> > dropping the extra arguments provided by the alias.\n>\n> This is intriguing: it would mean that an alias is not purely a\n> textual replacement? That's true for ! aliases today, but other than\n> shelling out it's pretty close.\n\nOne other thing I've just remembered: \"git help alias\" shows the alias\ninformation without running it. So I don't know if special-casing \"-h\"\nadds much?\n\n-- \nD. Ben Knoble\n"},{"id":"522851","messageId":"xmqqfregzb0r.fsf@gitster.g","threadId":"63846","inReplyTo":"20250726081254.GA3042329@coredump.intra.peff.net","subject":"Re: [PATCH] git: show alias info only with lone -h","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-07-28T13:43:16Z","receivedAt":"2025-07-28T13:43:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Another interesting case: even for our own commands, the alias itself\n> may add extra arguments, which confuses things further. So:\n>\n> $ git -c alias.gi='grep --cached' gi -h\n> 'gi' is aliased to 'grep --cached'\n> fatal: no pattern given\n>\n> runs git-grep, but even though the user said only \"-h\" the alias added\n> another option which prevents the help-mode from activating.\n>\n> In this case it is not too harmful, but you can come up with\n> pathological cases where it actually runs a real command:\n>\n> git -c alias.grep-for-foo='grep -e foo' grep-for-foo -h\n>\n> which runs a real grep.\n\nYes, that is an excellent point to further argue that we should fix\nthe help-alias case to stop there after describing the alias. The\nuser can choose to do \"git grep -h\" and look for \"--cached\" after\nlearning that their 'git gi' is a shorthand for 'git grep --cached\",\nbut we shouldn't be doing so.\n\n> I guess one way to deal with it would be if the user runs \"foo -h\", and\n> alias.foo is \"bar --other arguments\", then we run just \"bar -h\",\n> dropping the extra arguments provided by the alias.\n\nIt is much simpler and saner to just stop after giving the alias\nexpansion, isn't it? Nobody can get hurt if we did so; doing\nanything else would be driving us into further corner cases that\nwould either confuse or harm the users.\n\n> So IMHO the patch under discussion is a strict improvement, even though\n> it leaves many other questionable cases unsolved.\n\nThat part I 100% agree with. Let's accept the change, and then give\nfurther fixes in related areas.\n\n> I'd also be happy if on top we did:\n>\n> 1. When alias.foo=\"bar --options\", turn \"git foo -h\" into \"git bar\n> -h\", dropping \"--options\".\n\nThis smells like piling more voodoo magic on top, which I am not\nenthused.\n\n> 2. When alias.foo=\"!bar\", report only the alias and do not run \"bar\"\n> at all. The collateral damage here would be:\n>\n> !git bar $(some_shell_magic_we_need)\n>\n> but IMHO that is not all that bad. If we report the alias content,\n> the user can probably figure out which \"git help\" to run next.\n\nThis I very much like, and further, I would prefer to do this for\nall aliases.\n\nThanks.\n"},{"id":"522927","messageId":"20250729072345.GC1426859@coredump.intra.peff.net","threadId":"63846","inReplyTo":"CALnO6CA2qSYePJzqXjdW6c2zC4KQJSKzsCFCzc9si0OJ8E_ohw@mail.gmail.com","subject":"Re: [PATCH] git: show alias info only with lone -h","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-07-29T07:23:45Z","receivedAt":"2025-07-29T07:23:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jul 26, 2025 at 09:12:55AM -0400, D. Ben Knoble wrote:\n\n> > In this case it is not too harmful, but you can come up with\n> > pathological cases where it actually runs a real command:\n> >\n> > git -c alias.grep-for-foo='grep -e foo' grep-for-foo -h\n> >\n> > which runs a real grep.\n> >\n> > I guess one way to deal with it would be if the user runs \"foo -h\", and\n> > alias.foo is \"bar --other arguments\", then we run just \"bar -h\",\n> > dropping the extra arguments provided by the alias.\n> \n> This is intriguing: it would mean that an alias is not purely a\n> textual replacement? That's true for ! aliases today, but other than\n> shelling out it's pretty close.\n\nSort of. It's still a textual replacement for running the command. It's\njust that \"git foo -h\" is magic that puts us into help mode, and we try\nto communicate that help mode to the underlying command.\n\nSo I guess it depends on your point of view. :)\n\n> > So IMHO the patch under discussion is a strict improvement, even though\n> > it leaves many other questionable cases unsolved. I'd also be happy if\n> > on top we did:\n> >\n> > 1. When alias.foo=\"bar --options\", turn \"git foo -h\" into \"git bar\n> > -h\", dropping \"--options\".\n> >\n> > 2. When alias.foo=\"!bar\", report only the alias and do not run \"bar\"\n> > at all. The collateral damage here would be:\n> >\n> > !git bar $(some_shell_magic_we_need)\n> >\n> > but IMHO that is not all that bad. If we report the alias content,\n> > the user can probably figure out which \"git help\" to run next.\n> \n> And if the user actually wanted to run `bar -h`, say, because `-h`\n> didn't mean help for that command? I can't come up with a compelling\n> example, but this goes back to \"textual substitution\" vs. \"trying to\n> decide what the user actually wants.\"\n\nThis is leaning into the idea that \"git bar -h\" without other arguments\nshould _always_ mean help. We enforce it for our own commands (via a\ntest script). It's not enforced for third-party commands. If somebody\nfound a third-party command that violated this, I'd be tempted to say\n\"you're doing it wrong\". But that might not be feasible if it's\na command with an established history.\n\nBut I think this is already somewhat true, isn't it? If you have\nalias.foo=bar, then \"git foo -h\" is already treated as help. René's\npatch restricts that to the case of \"git foo -h\" and not \"git foo -h\nother-arg\", which is good. But I don't know if we are ready to get rid\nof \"git foo -h\" being alias-help at all.\n\n> At any rate, a (3) to consider is \"--help-all\": the patches I've been\n> working on are to make that flag work more often outside of Git\n> repositories. I just need to clean things up a bit and get to tests.\n> But if we do treat \"git alias -h\" specially, perhaps \"--help-all\" then\n> also warrants treatment.\n\nMost of the special-casing of \"-h\" now is just recognizing it when its\nalone to mean \"help\", even if the sub-command might recognize it as a\nnon-help option in other contexts. I don't think --help-all really needs\nthe same, since there's not much ambiguity to its meaning.\n\nBut yeah, if individual commands checked \"--help-all\" before insisting\non being in a repo (just like we do for \"-h\"), that seems like a good\nimprovement to me.\n\n-Peff\n"},{"id":"522928","messageId":"20250729072650.GD1426859@coredump.intra.peff.net","threadId":"63846","inReplyTo":"xmqqfregzb0r.fsf@gitster.g","subject":"Re: [PATCH] git: show alias info only with lone -h","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2025-07-29T07:26:50Z","receivedAt":"2025-07-29T07:26:51Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 28, 2025 at 06:43:16AM -0700, Junio C Hamano wrote:\n\n> > I guess one way to deal with it would be if the user runs \"foo -h\", and\n> > alias.foo is \"bar --other arguments\", then we run just \"bar -h\",\n> > dropping the extra arguments provided by the alias.\n> \n> It is much simpler and saner to just stop after giving the alias\n> expansion, isn't it? Nobody can get hurt if we did so; doing\n> anything else would be driving us into further corner cases that\n> would either confuse or harm the users.\n\nYeah, my suggestion was assuming that it is very valuable for \"git foo\n-h\" to not only print out the alias but to automatically print git-bar's\nhelp output. I don't know if people would miss it or not.\n\nBut...\n\n> > I'd also be happy if on top we did:\n> >\n> > 1. When alias.foo=\"bar --options\", turn \"git foo -h\" into \"git bar\n> > -h\", dropping \"--options\".\n> \n> This smells like piling more voodoo magic on top, which I am not\n> enthused.\n> \n> > 2. When alias.foo=\"!bar\", report only the alias and do not run \"bar\"\n> > at all. The collateral damage here would be:\n> >\n> > !git bar $(some_shell_magic_we_need)\n> >\n> > but IMHO that is not all that bad. If we report the alias content,\n> > the user can probably figure out which \"git help\" to run next.\n> \n> This I very much like, and further, I would prefer to do this for\n> all aliases.\n\n...yeah, after having slept on it, I am tempted to say that it is not\nthat valuable. And the best thing is to just stop running the\nsub-command automatically entirely, whether shell-based or not.\n\n-Peff\n"}]}