Jiang Xin <worldhello.net@xxxxxxxxx> writes: > Add subcommand "relative_path" in test-path-utils, and add test cases > in t0060. > > Johannes tested this commit on Windows, and found that some relative_path "this commit", or "an earlier version of this patch"? I am guessing it is the latter (if so, I can easily amend locally without a need for rerolling). > tests should be skipped on Windows. This is because the bash on Windows > rewrites arguments of regular Windows programs, such as git and the > test helpers, if the arguments look like absolute POSIX paths. As a > consequence, the actual tests performed are not what the tests scripts > expect. > > The tests that need *not* be skipped are those where the two paths passed > to 'test-path-utils relative_path' have the same prefix and the result is > expected to be a relative path. This is because the rewriting changes > "/a/b" to "D:/Src/MSysGit/a/b", and when both inputs are extended the same > way, this just cancels out in the relative path computation. > > Signed-off-by: Jiang Xin <worldhello.net@xxxxxxxxx> > Signed-off-by: Johannes Sixt <j6t@xxxxxxxx> > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> I somehow lost track, but does the above list of sign-offs reflect the origins of the changes contained in this patch, or is the second one meant to be helped-by or something (if so, I can easily amend locally without a need for rerolling)? > +relative_path / /a/b/ / POSIX > +relative_path /a/c /a/b/ /a/c POSIX > +relative_path /a/c /a/b /a/c POSIX (mental note, not a complaint): These are notable, as some may expect to see "..", "../.." and "../c" for these cases, but the rule is "ignore base and return it if it is absolute", so they are understandable. > +relative_path a a/b a # TODO: should be: .. > +relative_path x/y a/b x/y # TODO: should be: ../../x/y > +relative_path a/c a/b a/c # TODO: should be: ../c (mental note): OK. Let's see how they evolve in later patches. Thanks. -- 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