Re: [PATCH 10/10] t5710: use proper file:// URIs for absolute paths

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

Christian Couder <christian.couder@gmail.com> writes:

> +# On Windows, 'pwd' returns a path like 'D:/foo/bar'. Prepend '/' to turn
> +# it into '/D:/foo/bar', which is what git expects in file:// URLs on Windows.
> +# On Unix, the path already starts with '/', so this is a no-op.
> +pwd_path=$(pwd)
> +case "$pwd_path" in
> +[a-zA-Z]:*) pwd_path="/$pwd_path" ;;
> +esac
> +PWD_URL="file://$pwd_path"
> +# Same as PWD_URL but with spaces percent-encoded, for use in URL patterns.
> +ENCODED_PWD_URL="file://$(echo "$pwd_path" | sed "s/ /%20/g")"

Two comments.

 - I was a bit surprised that these are not given as functions but
   as variables, as a caller that chdirs around in the trash
   directory would want a URL that points at its current working
   directory (the expectation is from "pwd" in the name PWD_URL).
   But a variable based interface "Here is the URL that corresponds
   to the trash directory" is OK and probably easier to use than
   "give me the URL corresponding to my current working directory",
   simply because it allows a caller to append some string to it to
   come up with a URL for any subdirectory on its own without
   actually going there.  But in that case, the name PWD_URL would
   become misleading, as it is PWD as of the moment the variable
   gets defined, and the true meaning of the variable is not "URL
   for the current directory", but "URL for the trash directory" is
   more usable definition.

 - Is it sufficient to only special case SP?  My repository may be
   $HOME/w/git.git, for example, and the trash repository may be
   "$HOME/w/git.git/t/trash directory.t5710/", so you need to cope
   with SP between "trash" and "directory" the test framework adds
   (to force you to be careful), but the test framework does not
   control what can be in the leading $HOME part.