Jiang Xin <worldhello....@gmail.com> 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
> 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
> 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....@gmail.com>
> Signed-off-by: Johannes Sixt <j...@kdbg.org>
> Signed-off-by: Junio C Hamano <gits...@pobox.com>
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
> +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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html