Jiang Xin <worldhello.net@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html