Do not show empty split for Git help <cmd> on Windows

[andrey-starodubtsev]

Git for Windows shows help for its subcommands in a browser; so Git help rebase, for example, brings up empty split.

This commit covers notable exceptions to that: git help, git help -a, git help -g, git help --man and git --help.

[tpope]

What about with git help --man? Does that also show in a web browser?

[andrey-starodubtsev]

Yes, good point, added git help --man handling as well.

[tpope]

What about the help.format config option? Is that the true origin of this behavior?

I'm highly skeptical that has('win32') is what we should be keying off of. Just because we're running on Windows, that doesn't mean we're using "Git for Windows".

[andrey-starodubtsev]

okay, so it's a little bit more complicated

1. If none of --web/--man/--info is present in the command line, help.format is used. But if help.format is absent, then DEFAULT_HELP_FORMAT is used, which is defined to html for Windows (see https://github.com/git/git/blob/2c2ba49d55ff26c1082b8137b1ec5eeccb4337d1/config.mak.uname#L514). If it's not defined, default value for DEFAULT_HELP_FORMAT is used (which is man, see (https://github.com/git/git/blob/2c2ba49d55ff26c1082b8137b1ec5eeccb4337d1/builtin/help.c#L22).
2. It turns out that behavior of -h and --help is different: git -h rebase, git --help rebase and git rebase --help use help.format setting, but git rebase -h always prints help message to the console. git help, git --help and git -h, however, behave the same - print message to stdout.

Both Git for Windows and MinGW try to open help in browser by default; git's version is used to make a decision whether to open browser or split to show help if help.format is empty.