Re: [PATCH 1/2] help: introduce option --command-only

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 19, 2016, 08:32 UTC
Message-ID: <alpine.DEB.2.20.1608190954461.4924@virtualbox>
In-Reply-To: <20160818185719.4909-2-ralf.thielow@gmail.com>

Hi Ralf,

On Thu, 18 Aug 2016, Ralf Thielow wrote:

Show 16 quoted lines

> diff --git a/t/t0012-help.sh b/t/t0012-help.sh
> new file mode 100755
> index 0000000..e20f907
> --- /dev/null
> +++ b/t/t0012-help.sh
> @@ -0,0 +1,21 @@
> +#!/bin/sh
> +
> +test_description='help'
> +
> +. ./test-lib.sh
> +
> +test_expect_success "works for commands and guides by default" "
> +	git help status &&
> +	git help revisions
> +"

Apart from using double quotes (which is inconsistent with the single quotes used literally everwhere else in the test suite), this test is incorrect. If the man page is not *installed*, it will fail:

$ sudo mv /usr/share/man/man1/git-status.1.gz \
	/usr/share/man/man1/git-status.old.1.gz

$ sh t0012-help.sh -i -v -x
Initialized empty Git repository in .../trash directory.t0012-help/.git/
expecting success:
        git help status &&
        git help revisions

+ git help status
No manual entry for git-status
See 'man 7 undocumented' for help when manual pages are not available.
error: last command exited with $?=16
not ok 1 - works for commands and guides by default
#
#               git help status &&
#               git help revisions
#

It gets even worse.

On Windows, the default format is *not* man pages but html pages. So those would have to be installed, too, to guarantee that the test succeeds.

It gets *even* worse.

On Windows, there is really no central location for man/html pages for documentation, so we have to emulate that "prefix" (which is typically /usr on Linux) via a "runtime prefix", i.e. a prefix determined relative to the location of the currently running git executable. In the test suite's case, it is typically the top-level directory of the git.git checkout [*1*]. There are no man/html pages in that directory structure by default (I, for one, rarely build them myself), and certainly not in the place expected by this test.

It gets *even worse*.

Since the help.format is html on Windows, the page is opened by the default viewer for HTML pages. So even if all of the above would be fixed, running t0012-help of a supposedly unsupervised test suite would open new tabs in the web browser. Probably forcing it into the foreground, too.

So how about fixing that? I would suggest to do it this way:

- configure help.format = html (for "man", the current code would always
  add $(prefix)/share/man to the MANPATH when testing, not what we want,
  and hacking this code *just* for testing is both ugly and unnecessary).

- configure help.htmlpath to point to a subdirectory that is created and
  populated in the same test script.

- configure help.browser to point to a script that is created in the same
  script and whose output we can verify, too.

The last point actually requires a patch that was recently introduced into Git for Windows [*1*] (and that did not make it upstream yet) which reverts that change whereby web--browse was sidestepped. That sidestepping was well-intentioned but turned out to cause more harm than good.

Ciao, Johannes

Footnote *1*: That statement is actually not even correct. As the git executable can live in both $(prefix)/bin/ and $(prefix)/libexec/git-core, i.e. at different directory levels below the prefix, we need to inspect the *name* of the directory in which git.exe lives, and a git.git checkout typically lives in a .../git/ directory which matches *none* of the expected suffixes, so the runtime prefix defaults to "/", i.e. the *current drive's root directory*. So your current test would only succeed if the man pages for git-status and gitrevisions were copied into C:\mingw64\share\man\man1!

Footnote *2*: https://github.com/git-for-windows/git/commit/243c72f5b0