threads / patch / 42842

patchmingw: fix regression in t1308-config-set

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

## tl;dr

3 messages between Jul 14, 2016 and Jul 14, 2016. Diffs are folded; open one to read it.

replies: 2people: 3as markdown or json

Johannes Schindelin· Jul 14, 2016, 13:58 UTC · lore

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(-)

Show changes to t/t1308-config-set.sh +9 −1

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

Junio C Hamano· Jul 14, 2016, 16:18 UTC · re: Johannes Schindelin · lore

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

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.

Show 66 quoted lines

> 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

Jeff King· Jul 14, 2016, 18:40 UTC · re: Junio C Hamano · lore

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

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

Show 11 quoted lines

> 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.

Show 9 quoted lines

> > 	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