[PATCH] mingw: fix regression in t1308-config-set

[PATCH] mingw: fix regression in t1308-config-set

[Johannes Schindelin]

When we tried to fix in 58461bd (t1308: do not get fooled by symbolic
links to the source tree, 2016-06-02) an obscure case where the user
cd's into Git's source code via a symbolic link, a regression was
introduced that affects all test runs on Windows.

The original patch introducing the test case in question was careful to
use `$(pwd)` instead of `$PWD`.

This was done to account for the fact that Git's test suite uses shell
scripting even on Windows, where the shell's Unix-y paths are
incompatible with the main Git executable's idea of paths: it only
accepts Windows paths.

It is an awkward but necessary thing, then, to use `$(pwd)` (which gives
us a Windows path) when interacting with the Git executable and `$PWD`
(which gives the shell's idea of the current working directory in Unix-y
form) for shell scripts, including the test suite itself.

Obviously this broke the use case of the Git maintainer when changing
the working directory into Git's source code directory via a symlink,
i.e. when `$(pwd)` does not agree with `$PWD`.

However, we must not fix that use case at the expense of regressing
another use case.

Let's special-case Windows here, even if it is ugly, for lack of a more
elegant solution.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Published-As: https://github.com/dscho/git/releases/tag/t1308-on-windows-v1

	Side note: it was not at all clear to me how 58461bd fixed the
	problem by replacing $(pwd) with $HOME, given that HOME is set to
	$TRASH_DIRECTORY which is set to $TEST_OUTPUT_DIRECTORY/... after
	TEST_OUTPUT_DIRECTORY was set to TEST_DIRECTORY which in turn was
	set to $(pwd).

	I guess the reason is that -P in `cd -P "$TRASH DIRECTORY"`, but
	then I *really* do not understand how $(pwd) and $PWD could
	disagree.

	Oh well. I have to move on to the next fire.

 t/t1308-config-set.sh | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/t/t1308-config-set.sh b/t/t1308-config-set.sh
index a06e71c..7655c94 100755
--- a/t/t1308-config-set.sh
+++ b/t/t1308-config-set.sh
@@ -233,11 +233,19 @@ cmdline_config="'foo.bar=from-cmdline'"
 test_expect_success 'iteration shows correct origins' '
 	echo "[foo]bar = from-repo" >.git/config &&
 	echo "[foo]bar = from-home" >.gitconfig &&
+	if test_have_prereq MINGW
+	then
+		# Use Windows path (i.e. *not* $HOME)
+		HOME_GITCONFIG=$(pwd)/.gitconfig
+	else
+		# Do not get fooled by symbolic links, i.e. $HOME != $(pwd)
+		HOME_GITCONFIG=$HOME/.gitconfig
+	fi &&
 	cat >expect <<-EOF &&
 	key=foo.bar
 	value=from-home
 	origin=file
-	name=$HOME/.gitconfig
+	name=$HOME_GITCONFIG
 	scope=global
 
 	key=foo.bar
-- 
2.9.0.278.g1caae67

base-commit: 79ed43c28f626a4e805f350a77c54968b59be6e9

Re: [PATCH] mingw: fix regression in t1308-config-set

[Junio C Hamano]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> When we tried to fix in 58461bd (t1308: do not get fooled by symbolic
> links to the source tree, 2016-06-02) an obscure case where the user
> cd's into Git's source code via a symbolic link, a regression was
> introduced that affects all test runs on Windows.

Thanks for producing a fix quickly after the topic hit 'master'.

The original came from

  http://thread.gmane.org/gmane.comp.version-control.git/296021/focus=296199

which was merged at e5e5bb67 (Merge branch 'jk/upload-pack-hook'
into next, 2016-06-28) to 'next'.  

I see J6t raised C:/foo vs /c/foo issue in the thread later, but
unfortunately I didn't notice it.

I added a few missing Cc: and quoted the whole patch here to those
who were involved; I think this update is correct, but just trying
to make sure people know.

Not limited to this particular topic, there probably are some things
we can and should add to the procedure to prevent further episodes
like this, but I am not seeing anything immediately obvious offhand.
There already is a way to prominently mark a topic to be not-ready
with an outstanding issue called "What's cooking" report, but it is
maintained manually and it can be leaky without extra set of eyes
constantly monitoring.

> The original patch introducing the test case in question was careful to
> use `$(pwd)` instead of `$PWD`.
>
> This was done to account for the fact that Git's test suite uses shell
> scripting even on Windows, where the shell's Unix-y paths are
> incompatible with the main Git executable's idea of paths: it only
> accepts Windows paths.
>
> It is an awkward but necessary thing, then, to use `$(pwd)` (which gives
> us a Windows path) when interacting with the Git executable and `$PWD`
> (which gives the shell's idea of the current working directory in Unix-y
> form) for shell scripts, including the test suite itself.
>
> Obviously this broke the use case of the Git maintainer when changing
> the working directory into Git's source code directory via a symlink,
> i.e. when `$(pwd)` does not agree with `$PWD`.
>
> However, we must not fix that use case at the expense of regressing
> another use case.
>
> Let's special-case Windows here, even if it is ugly, for lack of a more
> elegant solution.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> Published-As: https://github.com/dscho/git/releases/tag/t1308-on-windows-v1
>
> 	Side note: it was not at all clear to me how 58461bd fixed the
> 	problem by replacing $(pwd) with $HOME, given that HOME is set to
> 	$TRASH_DIRECTORY which is set to $TEST_OUTPUT_DIRECTORY/... after
> 	TEST_OUTPUT_DIRECTORY was set to TEST_DIRECTORY which in turn was
> 	set to $(pwd).
>
> 	I guess the reason is that -P in `cd -P "$TRASH DIRECTORY"`, but
> 	then I *really* do not understand how $(pwd) and $PWD could
> 	disagree.
> 	Oh well. I have to move on to the next fire.
>
>  t/t1308-config-set.sh | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/t/t1308-config-set.sh b/t/t1308-config-set.sh
> index a06e71c..7655c94 100755
> --- a/t/t1308-config-set.sh
> +++ b/t/t1308-config-set.sh
> @@ -233,11 +233,19 @@ cmdline_config="'foo.bar=from-cmdline'"
>  test_expect_success 'iteration shows correct origins' '
>  	echo "[foo]bar = from-repo" >.git/config &&
>  	echo "[foo]bar = from-home" >.gitconfig &&
> +	if test_have_prereq MINGW
> +	then
> +		# Use Windows path (i.e. *not* $HOME)
> +		HOME_GITCONFIG=$(pwd)/.gitconfig
> +	else
> +		# Do not get fooled by symbolic links, i.e. $HOME != $(pwd)
> +		HOME_GITCONFIG=$HOME/.gitconfig
> +	fi &&
>  	cat >expect <<-EOF &&
>  	key=foo.bar
>  	value=from-home
>  	origin=file
> -	name=$HOME/.gitconfig
> +	name=$HOME_GITCONFIG
>  	scope=global
>  
>  	key=foo.bar

Re: [PATCH] mingw: fix regression in t1308-config-set

[Jeff King]

On Thu, Jul 14, 2016 at 09:18:18AM -0700, Junio C Hamano wrote:

> I added a few missing Cc: and quoted the whole patch here to those
> who were involved; I think this update is correct, but just trying
> to make sure people know.
> 
> Not limited to this particular topic, there probably are some things
> we can and should add to the procedure to prevent further episodes
> like this, but I am not seeing anything immediately obvious offhand.
> There already is a way to prominently mark a topic to be not-ready
> with an outstanding issue called "What's cooking" report, but it is
> maintained manually and it can be leaky without extra set of eyes
> constantly monitoring.

Thanks, this fix looks good.

I'm open to to suggestions to make life easier for Windows folks.
Usually when dealing with paths, the suggestion is to use $(pwd), which
I did in the original, but as 58461bd noted, that broke other cases.

So code-wise, maybe this technique could be more general. I.e., could
$TRASH_DIRECTORY or $HOME already be in whatever format is likely to be
produced by git on the platform? Or does that just screw things up more
because Windows sometimes needs one form and sometimes the other?

Process-wise, I'm not sure. I seem to recall a few times when Windows
issues have come up in the past that somebody (JSixt?) seemed content to
let topics graduate with potential portability problems, and then have
the Git for Windows project fix them up separately. These days GfW seems
to track upstream more closely (which is wonderful!), but it means
portability problems cause a more immediate headache and slow down that
process.

> > 	Side note: it was not at all clear to me how 58461bd fixed the
> > 	problem by replacing $(pwd) with $HOME, given that HOME is set to
> > 	$TRASH_DIRECTORY which is set to $TEST_OUTPUT_DIRECTORY/... after
> > 	TEST_OUTPUT_DIRECTORY was set to TEST_DIRECTORY which in turn was
> > 	set to $(pwd).
> >
> > 	I guess the reason is that -P in `cd -P "$TRASH DIRECTORY"`, but
> > 	then I *really* do not understand how $(pwd) and $PWD could
> > 	disagree.

I don't think they did disagree. The issue is that "cd -P" caused _both_
of them to print the physical directory. But git is not using either of
them. It is blindly using "$HOME". So basically:

  HOME=/path/with/symlinks
  cd -P "$HOME"

will cause "$PWD" and "$HOME" to disagree. Likewise with "$(pwd)" and
"$HOME".

-Peff