git help in Windows command prompt git help in Windows command prompt git git

git help in Windows command prompt


It works for particular commands: git <command> -h

Edit, thanks to @the-happy-hippo

But it shows only a brief description, not the full one, as git help <command> or git <command> --help gives on Windows.


git <verb> -h shows a command usage in the same terminal window.

On the other hand, git <verb> --help and git help <verb> open a browser.


Update for Git 2.x (June 2017, Git 2.13.1)

You still don't have man:

> git -c help.format=man help addwarning: failed to exec 'man': No such file or directoryfatal: no man viewer handled the request

Same for git <verb> --help.
git <verb> -h does not print the man page, only the short usage section (nothing to do with man)


With Git 2.34 (Q4 2021), when git cmd -h shows more than one line of usage text (e.g. the cmd subcommand may take sub-sub-command), parse-options API learned to align these lines, even across i18n/l10n.

See commit 4631cfc (21 Sep 2021), and commit 84122ec, commit 78a5091, commit 5d70198 (13 Sep 2021) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit d7bc852, 13 Oct 2021)

parse-options: properly align continued usage output

Signed-off-by: Ævar Arnfjörð Bjarmason

Some commands such as "git stash"(man) emit continued options output with e.g. git stash -h, because usage_with_options_internal() prefixes with its own whitespace the resulting output wasn't properly aligned.
Let's account for the added whitespace, which properly aligns the output.

The "git stash" command has usage output with a N_() translation that legitimately stretches across multiple lines;

N_("git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]\n"   "          [-u|--include-untracked] [-a|--all] [-m|--message <message>]\n"[...]

We'd like to have that output aligned with the length of the initial "git stash" output, but since usage_with_options_internal() adds its own whitespace prefixing we fell short, before this change we'd emit:

$ git stash -husage: git stash list [<options>]   or: git stash show [<options>] [<stash>]   [...]   or: git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]          [-u|--include-untracked] [-a|--all] [-m|--message <message>]          [...]

Now we'll properly emit aligned output.
I.e.
the last four lines above will instead be (a whitespace-only change to the above):

[...]or: git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]              [-u|--include-untracked] [-a|--all] [-m|--message <message>]              [...]

This change is relatively more complex since I've accounted for making it future-proof for RTL translation support.
Later in usage_with_options_internal() we have some existing padding code dating back to d7a38c5 ("parse-options: be able to generate usages automatically", 2007-10-15, Git v1.5.4-rc0 -- merge) which isn't RTL-safe, but that code would be easy to fix.
Let's not introduce new RTL translation problems here.


Original answer (2014)

No, even though an alternative, based on a 'cat' of the htlp txt files, is suggested in "how do I get git to show command-line help in windows?".

There man.<tool>.cmd config introduced in 2008, allows to set a custom command, but msys shell isn't shipped with man.exe.