git help in Windows command prompt

Question 1

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

You still don't have man:

> git -c help.format=man help add
warning: failed to exec 'man': No such file or directory
fatal: 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 -h
usage: 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.

Question 2

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.

Question 3

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.

Question 4

World's most overengineered workaround for this problem: use WSL

(that is, unless you already are a WSL user, in which case it's merely an ordinary workaround)

Install one of the linux distros via Windows Store
Go in and ensure it has the git package installed
From the Windows command line, bash -c 'git help fetch' etc.

Here's an alias for that last one:

[alias]
    hep = "!f() { $SYSTEMROOT/System32/bash -c \"git help $1\"; }; f"

(And no you can't override git built-ins, but you can make a shell command to intercept and reroute help.)

git help in Windows command prompt

parse-options: properly align continued usage output

`parse-options`: properly align continued usage output