Re: [PATCH v14 01/16] test: add test cases for relative_path

[Junio C Hamano <gitster@pobox.com>]

Jiang Xin <worldhello.net@gmail.com> writes:

> In order to test NULL pointer in t/t0060, I have to write normalize_argv_string
> to convert "<null>" to NULL....

Yes, null and empty I already understand.

> Add prefix _ to workaround the absolute path rewritten issue in
> msysGit is interesting, but these test cases have already been
> tested in Linux, right?

The most important thing is what we want to test in these tests.
The special test program is to try running the underlying
relative_path() by driving it directly, but the only real caller is
in setup_work_tree(), where two return values from real_path() is
compared.  On POSIX systems, we know we are feeding paths that both
begin with /.  Now, on Windows systems, what do we get back from
real_path()?  C:\git\Documentation?  /git/Documentation?  If the
former, then writing /a/b/c in the test input and letting Windows
bash convert it to C:\a\b\c before it calls the test-path-utils
would feed what we expect to see in the real caller, which would be
a more meaningful test than what I suggested (i.e. to feed _/a/b/c
to test-path-utils (unmolested by Windows bash), strip _ to feed
/a/b/c to underlying relative_path()).

Unlike relative_path() used in setup.c:setup_work_tree(), for
path_relative() from quote.c, IIRC, the expected inputs are both
full pathnames within the working tree.  A typical question the
callers to this function asks is like "The current directory
obtained from prefix is the Documentation/ directory and we need to
show that compat/mkdir.c is modified, relative to the current
directory.  ../compat/mkdir.c is what I want to show."  So in that
sense, it does not matter if /a/b/c is given as /a/b/c or C:\a\b\c
as we do not care the leading common part (either / or C:\) very
much.  On the other hand, the test vector you preoared in the first
test that all begin with / may not be very useful to make sure that
the function behaves the same way before and after your rewrite.