threads / patch / 41782

patch, 4 partsconfig --show-origin: report paths with forward slashes

Subject: [PATCH 1/4] config --show-origin: report paths with forward slashes

## tl;dr

42 messages between Mar 22, 2016 and Apr 4, 2016. Diffs are folded; open one to read it.

replies: 41people: 6as markdown or json

Johannes Schindelin· Mar 22, 2016, 17:42 UTC · lore

[PATCH 0/4] Git for Windows fixes in preparation for 2.8.0

The t1300 and t9115 tests regressed on Windows. These patches fix that.
Johannes Schindelin (4):
  config --show-origin: report paths with forward slashes
  Make t1300-repo-config resilient to being run via 'sh -x'
  t1300: fix the new --show-origin tests on Windows
  mingw: skip some tests in t9115 due to file name issues
 compat/mingw.h                           |  6 ++++++
 path.c                                   |  3 +++
 t/t1300-repo-config.sh                   | 23 ++++++++++++++---------
 t/t9115-git-svn-dcommit-funky-renames.sh |  4 ++--
 4 files changed, 25 insertions(+), 11 deletions(-)
-- 
2.7.4.windows.1
Johannes Schindelin· Mar 22, 2016, 17:42 UTC · re: Johannes Schindelin · lore

On Windows, the backslash is the native directory separator, but all supported Windows versions also accept the forward slash in most circumstances.

Our tests expect forward slashes.
Relative paths are generated by Git using forward slashes.

So let's try to be consistent and use forward slashes in the $HOME part of the paths reported by `git config --show-origin`, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 compat/mingw.h | 6 ++++++
 path.c         | 3 +++
 2 files changed, 9 insertions(+)
Show changes to 2 files +9 −0

compat/mingw.h, path.c

diff --git a/compat/mingw.h b/compat/mingw.h
index 8c5bf50..c008694 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -396,6 +396,12 @@ static inline char *mingw_find_last_dir_sep(const char *path)
 			ret = (char *)path;
 	return ret;
 }
+static inline void convert_slashes(char *path)
+{
+	for (; *path; path++)
+		if (*path == '\\')
+			*path = '/';
+}
 #define find_last_dir_sep mingw_find_last_dir_sep
 int mingw_offset_1st_component(const char *path);
 #define offset_1st_component mingw_offset_1st_component
diff --git a/path.c b/path.c
index 8b7e168..969b494 100644
--- a/path.c
+++ b/path.c
@@ -584,6 +584,9 @@ char *expand_user_path(const char *path)
 			if (!home)
 				goto return_null;
 			strbuf_addstr(&user_path, home);
+#ifdef GIT_WINDOWS_NATIVE
+			convert_slashes(user_path.buf);
+#endif
 		} else {
 			struct passwd *pw = getpw_str(username, username_len);
 			if (!pw)
-- 
2.7.4.windows.1
Junio C Hamano· Mar 22, 2016, 17:58 UTC · re: Johannes Schindelin · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Johannes Schindelin <johannes.schindelin@gmx.de> writes:
Show 7 quoted lines
> On Windows, the backslash is the native directory separator, but
> all supported Windows versions also accept the forward slash in
> most circumstances.
>
> Our tests expect forward slashes.
>
> Relative paths are generated by Git using forward slashes.
... and the paths tracked by Git (in the index) use slashes.
> So let's try to be consistent and use forward slashes in the $HOME
> part of the paths reported by `git config --show-origin`, too.
OK, sounds sensible.
Show 35 quoted lines
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  compat/mingw.h | 6 ++++++
>  path.c         | 3 +++
>  2 files changed, 9 insertions(+)
>
> diff --git a/compat/mingw.h b/compat/mingw.h
> index 8c5bf50..c008694 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -396,6 +396,12 @@ static inline char *mingw_find_last_dir_sep(const char *path)
>  			ret = (char *)path;
>  	return ret;
>  }
> +static inline void convert_slashes(char *path)
> +{
> +	for (; *path; path++)
> +		if (*path == '\\')
> +			*path = '/';
> +}
>  #define find_last_dir_sep mingw_find_last_dir_sep
>  int mingw_offset_1st_component(const char *path);
>  #define offset_1st_component mingw_offset_1st_component
> diff --git a/path.c b/path.c
> index 8b7e168..969b494 100644
> --- a/path.c
> +++ b/path.c
> @@ -584,6 +584,9 @@ char *expand_user_path(const char *path)
>  			if (!home)
>  				goto return_null;
>  			strbuf_addstr(&user_path, home);
> +#ifdef GIT_WINDOWS_NATIVE
> +			convert_slashes(user_path.buf);
> +#endif
Hmm, I wonder if we want to do this at a bit lower level, e.g.
    1. have a fallback for other platforms in git-compat-util.h
    #ifndef get_HOME
    #define get_HOME() getenv("HOME")
    #endif
    2. have the one that does convert-slashes for mingw
    static inline const char *mingw_getenv_HOME(void) {
    	... do convert-slashes on the result of getenv("HOME");
    }
    #define get_HOME() mingw_getenv_HOME()
    3. Instead of the above patch to path.c, change the line before
       the precontext with s/getenv("HOME")/get_HOME()/

Or even lower, inside mingw_getenv() and catch variables that deal with paths (not just HOME but PATH, TMP, TMPDIR, etc.)

>  		} else {
>  			struct passwd *pw = getpw_str(username, username_len);
>  			if (!pw)
Johannes Schindelin· Mar 23, 2016, 08:20 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Hi Junio,
On Tue, 22 Mar 2016, Junio C Hamano wrote:
Show 54 quoted lines
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > On Windows, the backslash is the native directory separator, but
> > all supported Windows versions also accept the forward slash in
> > most circumstances.
> >
> > Our tests expect forward slashes.
> >
> > Relative paths are generated by Git using forward slashes.
> 
> ... and the paths tracked by Git (in the index) use slashes.
> 
> > So let's try to be consistent and use forward slashes in the $HOME
> > part of the paths reported by `git config --show-origin`, too.
> 
> OK, sounds sensible.
> 
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  compat/mingw.h | 6 ++++++
> >  path.c         | 3 +++
> >  2 files changed, 9 insertions(+)
> >
> > diff --git a/compat/mingw.h b/compat/mingw.h
> > index 8c5bf50..c008694 100644
> > --- a/compat/mingw.h
> > +++ b/compat/mingw.h
> > @@ -396,6 +396,12 @@ static inline char *mingw_find_last_dir_sep(const char *path)
> >  			ret = (char *)path;
> >  	return ret;
> >  }
> > +static inline void convert_slashes(char *path)
> > +{
> > +	for (; *path; path++)
> > +		if (*path == '\\')
> > +			*path = '/';
> > +}
> >  #define find_last_dir_sep mingw_find_last_dir_sep
> >  int mingw_offset_1st_component(const char *path);
> >  #define offset_1st_component mingw_offset_1st_component
> > diff --git a/path.c b/path.c
> > index 8b7e168..969b494 100644
> > --- a/path.c
> > +++ b/path.c
> > @@ -584,6 +584,9 @@ char *expand_user_path(const char *path)
> >  			if (!home)
> >  				goto return_null;
> >  			strbuf_addstr(&user_path, home);
> > +#ifdef GIT_WINDOWS_NATIVE
> > +			convert_slashes(user_path.buf);
> > +#endif
> 
> Hmm, I wonder if we want to do this at a bit lower level,

Well, I tried to be careful. There *are* circumstamces when backslashes are required (CreateProcess() comes to mind), so I wanted to have this conversion as much only in the user-visible output as possible.

Show 7 quoted lines
> e.g.
> 
>     1. have a fallback for other platforms in git-compat-util.h
> 
>     #ifndef get_HOME
>     #define get_HOME() getenv("HOME")
>     #endif

Once upon a time, I had something like that (without the ugly uppercase, to account for the fact that Windows has no single HOME setting):

	http://thread.gmane.org/gmane.comp.version-control.msysgit/20339
Show 6 quoted lines
>     2. have the one that does convert-slashes for mingw
> 
>     static inline const char *mingw_getenv_HOME(void) {
>     	... do convert-slashes on the result of getenv("HOME");
>     }
>     #define get_HOME() mingw_getenv_HOME()
We could do that much easier now:
-- snip --
Show changes to compat/mingw.c +6 −1
diff --git a/compat/mingw.c b/compat/mingw.c
index 54c82ec..96022b7 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -2117,6 +2117,12 @@ static void setup_windows_environment()
 				*tmp = '/';
 	}
 
+	tmp = getenv("HOME");
+	if (tmp)
+		for (; *tmp; tmp++)
+			if (*tmp == '\\')
+				*tmp = '/';
+
 	/* simulate TERM to enable auto-color (see color.c) */
 	if (!getenv("TERM"))
 		setenv("TERM", "cygwin", 1);
-- snap --

But again, I am uncomfortable to do this wholesale without having the time
to do anything quickly about unintended side effects.


>     3. Instead of the above patch to path.c, change the line before
>        the precontext with s/getenv("HOME")/get_HOME()/
> 
> Or even lower, inside mingw_getenv() and catch variables that deal
> with paths (not just HOME but PATH, TMP, TMPDIR, etc.)

That outright scares me. Don't do that.

:-)

Again, just to make sure my point is heard: there *are* circumstances when
the Win32 API expects backslashes and cannot handle forward ones. I would
not dare to claim to be an expert in that matter, so I would rather want
to err on the side of converting backslashes to forward slashes *only*
when really needed.

Ciao,
Dscho
Junio C Hamano· Mar 23, 2016, 16:34 UTC · re: Johannes Schindelin · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 17 quoted lines
>> > diff --git a/path.c b/path.c
>> > index 8b7e168..969b494 100644
>> > --- a/path.c
>> > +++ b/path.c
>> > @@ -584,6 +584,9 @@ char *expand_user_path(const char *path)
>> >  			if (!home)
>> >  				goto return_null;
>> >  			strbuf_addstr(&user_path, home);
>> > +#ifdef GIT_WINDOWS_NATIVE
>> > +			convert_slashes(user_path.buf);
>> > +#endif
>> 
>> Hmm, I wonder if we want to do this at a bit lower level,
>
> Well, I tried to be careful. There *are* circumstamces when backslashes
> are required (CreateProcess() comes to mind), so I wanted to have this
> conversion as much only in the user-visible output as possible.

I was able to guess that it would be the reason, and I was willing to accept this as a short-term workaround.

As you are very well aware, the usual pattern we use is to implement a higher level function (e.g. expand_user_path() in this case) in terms of helpers that offer abstraction of implementation details that may be platform specific (e.g. getenv() may be implemented differently on Windows). An "#ifdef" in otherwise platform agnostic codepath like this one is a sign that the code is not well thought out to find the right abstraction to use to follow that pattern.

I was mostly reacting to that "#ifdef" and thinking aloud what the right abstraction is appropriate. As a short-term workaround, the above would have to do.

And no, I do not think convert_slashes() that becomes no-op on non-windows platforms is the right abstraction.

Johannes Sixt· Mar 28, 2016, 07:58 UTC · re: Johannes Schindelin · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Am 22.03.2016 um 18:42 schrieb Johannes Schindelin:
Show 49 quoted lines
> On Windows, the backslash is the native directory separator, but all
> supported Windows versions also accept the forward slash in most
> circumstances.
> 
> Our tests expect forward slashes.
> 
> Relative paths are generated by Git using forward slashes.
> 
> So let's try to be consistent and use forward slashes in the $HOME part
> of the paths reported by `git config --show-origin`, too.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>   compat/mingw.h | 6 ++++++
>   path.c         | 3 +++
>   2 files changed, 9 insertions(+)
> 
> diff --git a/compat/mingw.h b/compat/mingw.h
> index 8c5bf50..c008694 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -396,6 +396,12 @@ static inline char *mingw_find_last_dir_sep(const char *path)
>   			ret = (char *)path;
>   	return ret;
>   }
> +static inline void convert_slashes(char *path)
> +{
> +	for (; *path; path++)
> +		if (*path == '\\')
> +			*path = '/';
> +}
>   #define find_last_dir_sep mingw_find_last_dir_sep
>   int mingw_offset_1st_component(const char *path);
>   #define offset_1st_component mingw_offset_1st_component
> diff --git a/path.c b/path.c
> index 8b7e168..969b494 100644
> --- a/path.c
> +++ b/path.c
> @@ -584,6 +584,9 @@ char *expand_user_path(const char *path)
>   			if (!home)
>   				goto return_null;
>   			strbuf_addstr(&user_path, home);
> +#ifdef GIT_WINDOWS_NATIVE
> +			convert_slashes(user_path.buf);
> +#endif
>   		} else {
>   			struct passwd *pw = getpw_str(username, username_len);
>   			if (!pw)
> 
This change is not warranted for the following reasons:
- It is only there to satisfy the --show-origin tests, but not
  for the benefit of the users.
- The use of $HOME in those tests is just incidental, but not necessary.
- There is no reason to change only paths depending on $HOME,
  but no other paths imported through the environment.

I see no advantage for the users of --show-origin that they now see C:/foo/bar instead of C:\foo\bar. (For this reason, I'm not suggesting to change all paths imported from the environment, just the contrary, to leave them all alone).

A change like this whould have been preferable:
Show changes to t/t1300-repo-config.sh +9 −10
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 6767da8..4c96044 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1209,7 +1209,7 @@ test_expect_success POSIXPERM,PERL 'preserves existing permissions' '
 HOME="$(pwd)" # convert to Windows path
 
 test_expect_success 'set up --show-origin tests' '
-	INCLUDE_DIR="$HOME/include" &&
+	INCLUDE_DIR="$(pwd)/include" &&
 	mkdir -p "$INCLUDE_DIR" &&
 	cat >"$INCLUDE_DIR"/absolute.include <<-\EOF &&
 		[user]
@@ -1219,7 +1219,7 @@ test_expect_success 'set up --show-origin tests' '
 		[user]
 			relative = include
 	EOF
-	cat >"$HOME"/.gitconfig <<-EOF &&
+	cat >"$(pwd)"/.gitconfig <<-EOF &&
 		[user]
 			global = true
 			override = global
@@ -1237,9 +1237,9 @@ test_expect_success 'set up --show-origin tests' '
 
 test_expect_success '--show-origin with --list' '
 	cat >expect <<-EOF &&
-		file:$HOME/.gitconfig	user.global=true
-		file:$HOME/.gitconfig	user.override=global
-		file:$HOME/.gitconfig	include.path=$INCLUDE_DIR/absolute.include
+		file:$(pwd)/.gitconfig	user.global=true
+		file:$(pwd)/.gitconfig	user.override=global
+		file:$(pwd)/.gitconfig	include.path=$INCLUDE_DIR/absolute.include
 		file:$INCLUDE_DIR/absolute.include	user.absolute=include
 		file:.git/config	user.local=true
 		file:.git/config	user.override=local
@@ -1253,9 +1253,9 @@ test_expect_success '--show-origin with --list' '
 
 test_expect_success '--show-origin with --list --null' '
 	cat >expect <<-EOF &&
-		file:$HOME/.gitconfigQuser.global
-		trueQfile:$HOME/.gitconfigQuser.override
-		globalQfile:$HOME/.gitconfigQinclude.path
+		file:$(pwd)/.gitconfigQuser.global
+		trueQfile:$(pwd)/.gitconfigQuser.override
+		globalQfile:$(pwd)/.gitconfigQinclude.path
 		$INCLUDE_DIR/absolute.includeQfile:$INCLUDE_DIR/absolute.includeQuser.absolute
 		includeQfile:.git/configQuser.local
 		trueQfile:.git/configQuser.override
@@ -1284,7 +1284,7 @@ test_expect_success '--show-origin with single file' '
 
 test_expect_success '--show-origin with --get-regexp' '
 	cat >expect <<-EOF &&
-		file:$HOME/.gitconfig	user.global true
+		file:$(pwd)/.gitconfig	user.global true
 		file:.git/config	user.local true
 	EOF
 	git config --show-origin --get-regexp "user\.[g|l].*" >output &&

But it seems I'm late in the game. Can't I take a break for a week
without something odd happening to the Windows port...?

-- Hannes
Johannes Schindelin· Mar 28, 2016, 15:14 UTC · re: Johannes Sixt · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Hi Hannes,
On Mon, 28 Mar 2016, Johannes Sixt wrote:
> A change like this whould have been preferable:
> [...]

The problem with your patch is that it does not account for backslashes in paths resulting in quoting. I am afraid that your patch will most likely *not* let the tests pass in Git for Windows SDK, while my patch does.

Ciao, Dscho

Johannes Sixt· Mar 29, 2016, 19:18 UTC · re: Johannes Schindelin · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Am 28.03.2016 um 17:14 schrieb Johannes Schindelin:
Show 10 quoted lines
> Hi Hannes,
> 
> On Mon, 28 Mar 2016, Johannes Sixt wrote:
> 
>> A change like this whould have been preferable:
>> [...]
> 
> The problem with your patch is that it does not account for backslashes in
> paths resulting in quoting. I am afraid that your patch will most likely
> *not* let the tests pass in Git for Windows SDK, while my patch does.
It does pass. The reason is that pwd -W generates forward slashes.

This part of your 45bf3297 (t1300: fix the new --show-origin tests on Windows)

Show changes to diff +3 −1
@@ -1205,6 +1205,9 @@ test_expect_success POSIXPERM,PERL 'preserves existing per
          "die q(badrename) if ((stat(q(.git/config)))[2] & 07777) != 0600"
 '
 
+! test_have_prereq MINGW ||
+HOME="$(pwd)" # convert to Windows path
+
 test_expect_success 'set up --show-origin tests' '
        INCLUDE_DIR="$HOME/include" &&
        mkdir -p "$INCLUDE_DIR" &&

is actually a much more concise version of my proposed patch,
although the result still misuses $HOME where it does not have
to. In fact, if I revert 5ca6b7bb (config --show-origin: report
paths with forward slashes), the tests still pass. But since it
does not make a difference save for a few microseconds more or
less during startup, it is not worth the churn at this point.

-- Hannes
Junio C Hamano· Mar 29, 2016, 20:05 UTC · re: Johannes Sixt · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Johannes Sixt <j6t@kdbg.org> writes:
Show 20 quoted lines
> This part of your 45bf3297 (t1300: fix the new --show-origin tests on
> Windows)
>
> @@ -1205,6 +1205,9 @@ test_expect_success POSIXPERM,PERL 'preserves existing per
>           "die q(badrename) if ((stat(q(.git/config)))[2] & 07777) != 0600"
>  '
>  
> +! test_have_prereq MINGW ||
> +HOME="$(pwd)" # convert to Windows path
> +
>  test_expect_success 'set up --show-origin tests' '
>         INCLUDE_DIR="$HOME/include" &&
>         mkdir -p "$INCLUDE_DIR" &&
>
> is actually a much more concise version of my proposed patch,
> although the result still misuses $HOME where it does not have
> to. In fact, if I revert 5ca6b7bb (config --show-origin: report
> paths with forward slashes), the tests still pass. But since it
> does not make a difference save for a few microseconds more or
> less during startup, it is not worth the churn at this point.

Well, from the point of view of codebase cleanliness, if we can do without 5ca6b7bb4, we would be much better off in the longer term, so I would say it would be wonderful if we can safely revert it.

Johannes Sixt· Apr 2, 2016, 19:03 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Am 29.03.2016 um 22:05 schrieb Junio C Hamano:
Show 26 quoted lines
> Johannes Sixt <j6t@kdbg.org> writes:
> 
>> This part of your 45bf3297 (t1300: fix the new --show-origin tests on
>> Windows)
>>
>> @@ -1205,6 +1205,9 @@ test_expect_success POSIXPERM,PERL 'preserves existing per
>>            "die q(badrename) if ((stat(q(.git/config)))[2] & 07777) != 0600"
>>   '
>>   
>> +! test_have_prereq MINGW ||
>> +HOME="$(pwd)" # convert to Windows path
>> +
>>   test_expect_success 'set up --show-origin tests' '
>>          INCLUDE_DIR="$HOME/include" &&
>>          mkdir -p "$INCLUDE_DIR" &&
>>
>> is actually a much more concise version of my proposed patch,
>> although the result still misuses $HOME where it does not have
>> to. In fact, if I revert 5ca6b7bb (config --show-origin: report
>> paths with forward slashes), the tests still pass. But since it
>> does not make a difference save for a few microseconds more or
>> less during startup, it is not worth the churn at this point.
> 
> Well, from the point of view of codebase cleanliness, if we can do
> without 5ca6b7bb4, we would be much better off in the longer term,
> so I would say it would be wonderful if we can safely revert it.

Although I am convinced that the change is not necessary for correctness, I can buy the justification that we should produce forward slashes for consistency. There are a number of occasions where we present paths to the user, and we do show forward-slashes in all cases that I found. We should keep the commit.

But then let's do this:
---- 8< ----
Subject: [PATCH] Windows: shorten code by re-using convert_slashes()

Make a few more spots more readable by using the recently introduced, Windows-specific helper.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
 abspath.c      | 5 +----
 compat/mingw.c | 9 ++-------
 2 files changed, 3 insertions(+), 11 deletions(-)
Show changes to 2 files +3 −11

abspath.c, compat/mingw.c

diff --git a/abspath.c b/abspath.c
index 5edb4e7..2825de8 100644
--- a/abspath.c
+++ b/abspath.c
@@ -167,7 +167,6 @@ const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
 	strbuf_add(&path, pfx, pfx_len);
 	strbuf_addstr(&path, arg);
 #else
-	char *p;
 	/* don't add prefix to absolute paths, but still replace '\' by '/' */
 	strbuf_reset(&path);
 	if (is_absolute_path(arg))
@@ -175,9 +174,7 @@ const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
 	else if (pfx_len)
 		strbuf_add(&path, pfx, pfx_len);
 	strbuf_addstr(&path, arg);
-	for (p = path.buf + pfx_len; *p; p++)
-		if (*p == '\\')
-			*p = '/';
+	convert_slashes(path.buf + pfx_len);
 #endif
 	return path.buf;
 }
diff --git a/compat/mingw.c b/compat/mingw.c
index 54c82ec..0413d5c 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -763,15 +763,12 @@ struct tm *localtime_r(const time_t *timep, struct tm *result)
 
 char *mingw_getcwd(char *pointer, int len)
 {
-	int i;
 	wchar_t wpointer[MAX_PATH];
 	if (!_wgetcwd(wpointer, ARRAY_SIZE(wpointer)))
 		return NULL;
 	if (xwcstoutf(pointer, wpointer, len) < 0)
 		return NULL;
-	for (i = 0; pointer[i]; i++)
-		if (pointer[i] == '\\')
-			pointer[i] = '/';
+	convert_slashes(pointer);
 	return pointer;
 }
 
@@ -2112,9 +2109,7 @@ static void setup_windows_environment()
 		 * executable (by not mistaking the dir separators
 		 * for escape characters).
 		 */
-		for (; *tmp; tmp++)
-			if (*tmp == '\\')
-				*tmp = '/';
+		convert_slashes(tmp);
 	}
 
 	/* simulate TERM to enable auto-color (see color.c) */
-- 
2.7.0.118.g90056ae
Junio C Hamano· Apr 4, 2016, 15:51 UTC · re: Johannes Sixt · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Johannes Sixt <j6t@kdbg.org> writes:
Show 7 quoted lines
> Although I am convinced that the change is not necessary for
> correctness, I can buy the justification that we should produce forward
> slashes for consistency. There are a number of occasions where we
> present paths to the user, and we do show forward-slashes in all cases
> that I found. We should keep the commit.
>
> But then let's do this:

Sounds like a plan; even though I am mildly against adding more platform specific #ifdef to files outside compat/, this patch does not.

Dscho?
Show 68 quoted lines
>
> ---- 8< ----
> Subject: [PATCH] Windows: shorten code by re-using convert_slashes()
>
> Make a few more spots more readable by using the recently introduced,
> Windows-specific helper.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
>  abspath.c      | 5 +----
>  compat/mingw.c | 9 ++-------
>  2 files changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/abspath.c b/abspath.c
> index 5edb4e7..2825de8 100644
> --- a/abspath.c
> +++ b/abspath.c
> @@ -167,7 +167,6 @@ const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
>  	strbuf_add(&path, pfx, pfx_len);
>  	strbuf_addstr(&path, arg);
>  #else
> -	char *p;
>  	/* don't add prefix to absolute paths, but still replace '\' by '/' */
>  	strbuf_reset(&path);
>  	if (is_absolute_path(arg))
> @@ -175,9 +174,7 @@ const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
>  	else if (pfx_len)
>  		strbuf_add(&path, pfx, pfx_len);
>  	strbuf_addstr(&path, arg);
> -	for (p = path.buf + pfx_len; *p; p++)
> -		if (*p == '\\')
> -			*p = '/';
> +	convert_slashes(path.buf + pfx_len);
>  #endif
>  	return path.buf;
>  }
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 54c82ec..0413d5c 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -763,15 +763,12 @@ struct tm *localtime_r(const time_t *timep, struct tm *result)
>  
>  char *mingw_getcwd(char *pointer, int len)
>  {
> -	int i;
>  	wchar_t wpointer[MAX_PATH];
>  	if (!_wgetcwd(wpointer, ARRAY_SIZE(wpointer)))
>  		return NULL;
>  	if (xwcstoutf(pointer, wpointer, len) < 0)
>  		return NULL;
> -	for (i = 0; pointer[i]; i++)
> -		if (pointer[i] == '\\')
> -			pointer[i] = '/';
> +	convert_slashes(pointer);
>  	return pointer;
>  }
>  
> @@ -2112,9 +2109,7 @@ static void setup_windows_environment()
>  		 * executable (by not mistaking the dir separators
>  		 * for escape characters).
>  		 */
> -		for (; *tmp; tmp++)
> -			if (*tmp == '\\')
> -				*tmp = '/';
> +		convert_slashes(tmp);
>  	}
>  
>  	/* simulate TERM to enable auto-color (see color.c) */
Johannes Schindelin· Apr 4, 2016, 20:42 UTC · re: Junio C Hamano · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Hi Junio,
On Mon, 4 Apr 2016, Junio C Hamano wrote:
Show 15 quoted lines
> Johannes Sixt <j6t@kdbg.org> writes:
> 
> > Although I am convinced that the change is not necessary for
> > correctness, I can buy the justification that we should produce forward
> > slashes for consistency. There are a number of occasions where we
> > present paths to the user, and we do show forward-slashes in all cases
> > that I found. We should keep the commit.
> >
> > But then let's do this:
> 
> Sounds like a plan; even though I am mildly against adding more
> platform specific #ifdef to files outside compat/, this patch does
> not.
> 
> Dscho?

Fine by me! Dscho

Johannes Sixt· Mar 30, 2016, 05:52 UTC · re: Johannes Sixt · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Am 29.03.2016 um 21:18 schrieb Johannes Sixt:
Show 6 quoted lines
> Am 28.03.2016 um 17:14 schrieb Johannes Schindelin:
>> The problem with your patch is that it does not account for backslashes in
>> paths resulting in quoting. I am afraid that your patch will most likely
>> *not* let the tests pass in Git for Windows SDK, while my patch does.
>
> It does pass. The reason is that pwd -W generates forward slashes.

It just occurred to me that we might be observing a difference in behavior of pwd -W between the modern MSYS2 bash and the old MSYS1 bash that I am using. If that is the case the tests won't pass under MSYS2 without the change made by 5ca6b7bb (config --show-origin: report paths with forward slashes).

-- Hannes
Johannes Sixt· Apr 2, 2016, 18:51 UTC · re: Johannes Sixt · lore

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Am 30.03.2016 um 07:52 schrieb Johannes Sixt:
Show 6 quoted lines
> Am 29.03.2016 um 21:18 schrieb Johannes Sixt:
>> It does pass. The reason is that pwd -W generates forward slashes.
>
> It just occurred to me that we might be observing a difference in
> behavior of pwd -W between the modern MSYS2 bash and the old MSYS1 bash
> that I am using.
No that isn't it. Both versions produce forward slashes. Puzzled...
-- Hannes
Johannes Schindelin· Mar 22, 2016, 17:42 UTC · re: Johannes Schindelin · lore

[PATCH 2/4] Make t1300-repo-config resilient to being run via 'sh -x'

One of this developer's primary tools to diagnose broken regression tests is to run the test script using 'sh -x t... -i -v' to find out *which* call *actually* demonstrates the symptom.

Hence it is pretty counterproductive if the test script behaves differently when being run via 'sh -x', in particular when using test_cmp or test_i18ncmp on redirected stderr.

So let's use grep instead of test_cmp/test_i18ncmp to verify that stderr looks as expected.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1300-repo-config.sh | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)
Show changes to t/t1300-repo-config.sh +2 −6
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 8867ce1..0236fe2 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -699,17 +699,13 @@ test_expect_success 'invalid unit' '
 	echo 1auto >expect &&
 	git config aninvalid.unit >actual &&
 	test_cmp expect actual &&
-	cat >expect <<-\EOF &&
-	fatal: bad numeric config value '\''1auto'\'' for '\''aninvalid.unit'\'' in file .git/config: invalid unit
-	EOF
 	test_must_fail git config --int --get aninvalid.unit 2>actual &&
-	test_i18ncmp expect actual
+	grep "^fatal: bad numeric config value .1auto. for .aninvalid.unit. in file .git/config: invalid unit$" actual
 '
 
 test_expect_success 'invalid stdin config' '
-	echo "fatal: bad config line 1 in standard input " >expect &&
 	echo "[broken" | test_must_fail git config --list --file - >output 2>&1 &&
-	test_cmp expect output
+	grep "^fatal: bad config line 1 in standard input $" output
 '
 
 cat > expect << EOF
-- 
2.7.4.windows.1
Jonathan Nieder· Mar 22, 2016, 17:59 UTC · re: Johannes Schindelin · lore

Re: [PATCH 2/4] Make t1300-repo-config resilient to being run via 'sh -x'

Johannes Schindelin wrote:
Show 12 quoted lines
> --- a/t/t1300-repo-config.sh
> +++ b/t/t1300-repo-config.sh
> @@ -699,17 +699,13 @@ test_expect_success 'invalid unit' '
>  	echo 1auto >expect &&
>  	git config aninvalid.unit >actual &&
>  	test_cmp expect actual &&
> -	cat >expect <<-\EOF &&
> -	fatal: bad numeric config value '\''1auto'\'' for '\''aninvalid.unit'\'' in file .git/config: invalid unit
> -	EOF
>  	test_must_fail git config --int --get aninvalid.unit 2>actual &&
> -	test_i18ncmp expect actual
> +	grep "^fatal: bad numeric config value .1auto. for .aninvalid.unit. in file .git/config: invalid unit$" actual
Would test_i18ngrep work?
Show 7 quoted lines
>  '
>  
>  test_expect_success 'invalid stdin config' '
> -	echo "fatal: bad config line 1 in standard input " >expect &&
>  	echo "[broken" | test_must_fail git config --list --file - >output 2>&1 &&
> -	test_cmp expect output
> +	grep "^fatal: bad config line 1 in standard input $" output

This test is very strange. Why do we care that it starts with "fatal:" as opposed to error? Why are we testing for an extra space at the end of the line?

I would expect something like
	test_i18ngrep 'line 1 in standard input' output

to be more useful for testing the useful part of the error message while remaining resilient against error message changes.

Thanks, Jonathan

Junio C Hamano· Mar 22, 2016, 20:34 UTC · re: Jonathan Nieder · lore

Re: [PATCH 2/4] Make t1300-repo-config resilient to being run via 'sh -x'

Jonathan Nieder <jrnieder@gmail.com> writes:
Show 35 quoted lines
> Johannes Schindelin wrote:
>
>> --- a/t/t1300-repo-config.sh
>> +++ b/t/t1300-repo-config.sh
>> @@ -699,17 +699,13 @@ test_expect_success 'invalid unit' '
>>  	echo 1auto >expect &&
>>  	git config aninvalid.unit >actual &&
>>  	test_cmp expect actual &&
>> -	cat >expect <<-\EOF &&
>> -	fatal: bad numeric config value '\''1auto'\'' for '\''aninvalid.unit'\'' in file .git/config: invalid unit
>> -	EOF
>>  	test_must_fail git config --int --get aninvalid.unit 2>actual &&
>> -	test_i18ncmp expect actual
>> +	grep "^fatal: bad numeric config value .1auto. for .aninvalid.unit. in file .git/config: invalid unit$" actual
>
> Would test_i18ngrep work?
>
>>  '
>>  
>>  test_expect_success 'invalid stdin config' '
>> -	echo "fatal: bad config line 1 in standard input " >expect &&
>>  	echo "[broken" | test_must_fail git config --list --file - >output 2>&1 &&
>> -	test_cmp expect output
>> +	grep "^fatal: bad config line 1 in standard input $" output
>
> This test is very strange.  Why do we care that it starts with
> "fatal:" as opposed to error?  Why are we testing for an extra space at
> the end of the line?
>
> I would expect something like
>
> 	test_i18ngrep 'line 1 in standard input' output
>
> to be more useful for testing the useful part of the error message while
> remaining resilient against error message changes.
Both sounds sensible.  Should we squash this in, then?
 t/t1300-repo-config.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Show changes to t/t1300-repo-config.sh +2 −2
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 0236fe2..dca27a3 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -700,12 +700,12 @@ test_expect_success 'invalid unit' '
 	git config aninvalid.unit >actual &&
 	test_cmp expect actual &&
 	test_must_fail git config --int --get aninvalid.unit 2>actual &&
-	grep "^fatal: bad numeric config value .1auto. for .aninvalid.unit. in file .git/config: invalid unit$" actual
+	test_i18ngrep "bad numeric config value .1auto. for .aninvalid.unit. in file .git/config: invalid unit" actual
 '
 
 test_expect_success 'invalid stdin config' '
 	echo "[broken" | test_must_fail git config --list --file - >output 2>&1 &&
-	grep "^fatal: bad config line 1 in standard input $" output
+	test_i18ngrep "bad config line 1 in standard input" output
 '
 
 cat > expect << EOF
Jonathan Nieder· Mar 22, 2016, 23:45 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/4] Make t1300-repo-config resilient to being run via 'sh -x'

Junio C Hamano wrote:
> Both sounds sensible.  Should we squash this in, then?
>
>  t/t1300-repo-config.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks.
Johannes Schindelin· Mar 23, 2016, 07:21 UTC · re: Jonathan Nieder · lore

Re: [PATCH 2/4] Make t1300-repo-config resilient to being run via 'sh -x'

Hi,
On Tue, 22 Mar 2016, Jonathan Nieder wrote:
Show 8 quoted lines
> Junio C Hamano wrote:
> 
> > Both sounds sensible.  Should we squash this in, then?
> >
> >  t/t1300-repo-config.sh | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

Sure, makes sense. That late in the 2.8.0 game I tried to err on the more faithful side, hence I kept testing for "fatal:" but if you two are fine with dropping it...

Ciao, Dscho

Junio C Hamano· Mar 22, 2016, 18:01 UTC · re: Johannes Schindelin · lore

Re: [PATCH 2/4] Make t1300-repo-config resilient to being run via 'sh -x'

Johannes Schindelin <johannes.schindelin@gmx.de> writes:
Show 10 quoted lines
> One of this developer's primary tools to diagnose broken regression
> tests is to run the test script using 'sh -x t... -i -v' to find out
> *which* call *actually* demonstrates the symptom.
>
> Hence it is pretty counterproductive if the test script behaves
> differently when being run via 'sh -x', in particular when using
> test_cmp or test_i18ncmp on redirected stderr.
>
> So let's use grep instead of test_cmp/test_i18ncmp to verify that stderr
> looks as expected.

In the modern world, I would probably described the problem as "tXXXX -i -v -x", though, not "sh -x tXXXX", but they both exhibit the same symptom.

I wonder if "tXXXX -i -v -x" can be made not to contaminate the standard error stream of the test, but that would be a larger change we probably would not have time for 2.8 final anyway.

Will queue.  Thanks.
Show 30 quoted lines
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  t/t1300-repo-config.sh | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
> index 8867ce1..0236fe2 100755
> --- a/t/t1300-repo-config.sh
> +++ b/t/t1300-repo-config.sh
> @@ -699,17 +699,13 @@ test_expect_success 'invalid unit' '
>  	echo 1auto >expect &&
>  	git config aninvalid.unit >actual &&
>  	test_cmp expect actual &&
> -	cat >expect <<-\EOF &&
> -	fatal: bad numeric config value '\''1auto'\'' for '\''aninvalid.unit'\'' in file .git/config: invalid unit
> -	EOF
>  	test_must_fail git config --int --get aninvalid.unit 2>actual &&
> -	test_i18ncmp expect actual
> +	grep "^fatal: bad numeric config value .1auto. for .aninvalid.unit. in file .git/config: invalid unit$" actual
>  '
>  
>  test_expect_success 'invalid stdin config' '
> -	echo "fatal: bad config line 1 in standard input " >expect &&
>  	echo "[broken" | test_must_fail git config --list --file - >output 2>&1 &&
> -	test_cmp expect output
> +	grep "^fatal: bad config line 1 in standard input $" output
>  '
>  
>  cat > expect << EOF
Johannes Schindelin· Mar 23, 2016, 08:22 UTC · re: Junio C Hamano · lore

Re: [PATCH 2/4] Make t1300-repo-config resilient to being run via 'sh -x'

Hi Junio,
On Tue, 22 Mar 2016, Junio C Hamano wrote:
Show 16 quoted lines
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > One of this developer's primary tools to diagnose broken regression
> > tests is to run the test script using 'sh -x t... -i -v' to find out
> > *which* call *actually* demonstrates the symptom.
> >
> > Hence it is pretty counterproductive if the test script behaves
> > differently when being run via 'sh -x', in particular when using
> > test_cmp or test_i18ncmp on redirected stderr.
> >
> > So let's use grep instead of test_cmp/test_i18ncmp to verify that stderr
> > looks as expected.
> 
> In the modern world, I would probably described the problem as
> "tXXXX -i -v -x", though, not "sh -x tXXXX", but they both exhibit
> the same symptom.

Thanks for pointing me to -i -v -x. The introduction of the RHS -x somehow slipped by me.

> I wonder if "tXXXX -i -v -x" can be made not to contaminate the
> standard error stream of the test, but that would be a larger change
> we probably would not have time for 2.8 final anyway.
Agree, both on "we want to have this" and "after 2.8".

Ciao, Dscho

Johannes Schindelin· Mar 22, 2016, 17:42 UTC · re: Johannes Schindelin · lore

[PATCH 3/4] t1300: fix the new --show-origin tests on Windows

On Windows, we have that funny situation where the test script can refer to POSIX paths because it runs in a shell that uses a POSIX emulation layer ("MSYS2 runtime"). Yet, git.exe does *not* understand POSIX paths at all but only pure Windows paths.

So let's just convert the POSIX paths to Windows paths before passing them on to Git, using `pwd` (which is already modified on Windows to output Windows paths).

While fixing the new tests on Windows, we also have to exclude the tests that want to write a file with a name that is illegal on Windows (unfortunately, there is more than one test trying to make use of that file).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1300-repo-config.sh | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)
Show changes to t/t1300-repo-config.sh +12 −3
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 0236fe2..18eb769 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1232,6 +1232,15 @@ test_expect_success 'set up --show-origin tests' '
 	EOF
 '
 
+if test_have_prereq MINGW
+then
+	# convert to Windows paths
+	HOME="$(pwd)"
+	INCLUDE_DIR="$HOME/include"
+	export HOME INCLUDE_DIR
+	git config -f .gitconfig include.path "$INCLUDE_DIR/absolute.include"
+fi
+
 test_expect_success '--show-origin with --list' '
 	cat >expect <<-EOF &&
 		file:$HOME/.gitconfig	user.global=true
@@ -1304,7 +1313,7 @@ test_expect_success 'set up custom config file' '
 	EOF
 '
 
-test_expect_success '--show-origin escape special file name characters' '
+test_expect_success !MINGW '--show-origin escape special file name characters' '
 	cat >expect <<-\EOF &&
 		file:"file\" (dq) and spaces.conf"	user.custom=true
 	EOF
@@ -1333,7 +1342,7 @@ test_expect_success '--show-origin stdin with file include' '
 	test_cmp expect output
 '
 
-test_expect_success '--show-origin blob' '
+test_expect_success !MINGW '--show-origin blob' '
 	cat >expect <<-\EOF &&
 		blob:a9d9f9e555b5c6f07cbe09d3f06fe3df11e09c08	user.custom=true
 	EOF
@@ -1342,7 +1351,7 @@ test_expect_success '--show-origin blob' '
 	test_cmp expect output
 '
 
-test_expect_success '--show-origin blob ref' '
+test_expect_success !MINGW '--show-origin blob ref' '
 	cat >expect <<-\EOF &&
 		blob:"master:file\" (dq) and spaces.conf"	user.custom=true
 	EOF
-- 
2.7.4.windows.1
Junio C Hamano· Mar 22, 2016, 18:13 UTC · re: Johannes Schindelin · lore

Re: [PATCH 3/4] t1300: fix the new --show-origin tests on Windows

Johannes Schindelin <johannes.schindelin@gmx.de> writes:
Show 31 quoted lines
> On Windows, we have that funny situation where the test script can refer
> to POSIX paths because it runs in a shell that uses a POSIX emulation
> layer ("MSYS2 runtime"). Yet, git.exe does *not* understand POSIX paths
> at all but only pure Windows paths.
>
> So let's just convert the POSIX paths to Windows paths before passing
> them on to Git, using `pwd` (which is already modified on Windows to
> output Windows paths).
>
> While fixing the new tests on Windows, we also have to exclude the tests
> that want to write a file with a name that is illegal on Windows
> (unfortunately, there is more than one test trying to make use of that
> file).
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  t/t1300-repo-config.sh | 15 ++++++++++++---
>  1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
> index 0236fe2..18eb769 100755
> --- a/t/t1300-repo-config.sh
> +++ b/t/t1300-repo-config.sh
> @@ -1232,6 +1232,15 @@ test_expect_success 'set up --show-origin tests' '
>  	EOF
>  '
>  
> +if test_have_prereq MINGW
> +then
> +	# convert to Windows paths
> +	HOME="$(pwd)"
We override HOME in t/test-lib.sh; shouldn't this be done there?
> +	INCLUDE_DIR="$HOME/include"

I am puzzled. 'set up --show-origin tests' do say INCLUDE_DIR is "$HOME/include" already, so why is this needed?

> +	export HOME INCLUDE_DIR

Existing tests use $INCLUDE_DIR (and $HOME) as shell variables just fine without exporting. Why do these need to be exported only on MINGW?

> +	git config -f .gitconfig include.path "$INCLUDE_DIR/absolute.include"
> +fi

Perhaps if you adjust HOME before 'set up --show-origin tests' test, most (or all) of the above become unnecessary?

The changes below that skip tests that relies on pathnames that cannot be used on Windows makes sense, though.

Show 30 quoted lines
>  test_expect_success '--show-origin with --list' '
>  	cat >expect <<-EOF &&
>  		file:$HOME/.gitconfig	user.global=true
> @@ -1304,7 +1313,7 @@ test_expect_success 'set up custom config file' '
>  	EOF
>  '
>  
> -test_expect_success '--show-origin escape special file name characters' '
> +test_expect_success !MINGW '--show-origin escape special file name characters' '
>  	cat >expect <<-\EOF &&
>  		file:"file\" (dq) and spaces.conf"	user.custom=true
>  	EOF
> @@ -1333,7 +1342,7 @@ test_expect_success '--show-origin stdin with file include' '
>  	test_cmp expect output
>  '
>  
> -test_expect_success '--show-origin blob' '
> +test_expect_success !MINGW '--show-origin blob' '
>  	cat >expect <<-\EOF &&
>  		blob:a9d9f9e555b5c6f07cbe09d3f06fe3df11e09c08	user.custom=true
>  	EOF
> @@ -1342,7 +1351,7 @@ test_expect_success '--show-origin blob' '
>  	test_cmp expect output
>  '
>  
> -test_expect_success '--show-origin blob ref' '
> +test_expect_success !MINGW '--show-origin blob ref' '
>  	cat >expect <<-\EOF &&
>  		blob:"master:file\" (dq) and spaces.conf"	user.custom=true
>  	EOF
Johannes Schindelin· Mar 23, 2016, 10:42 UTC · re: Junio C Hamano · lore

Re: [PATCH 3/4] t1300: fix the new --show-origin tests on Windows

Hi Junio,
On Tue, 22 Mar 2016, Junio C Hamano wrote:
Show 35 quoted lines
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > On Windows, we have that funny situation where the test script can refer
> > to POSIX paths because it runs in a shell that uses a POSIX emulation
> > layer ("MSYS2 runtime"). Yet, git.exe does *not* understand POSIX paths
> > at all but only pure Windows paths.
> >
> > So let's just convert the POSIX paths to Windows paths before passing
> > them on to Git, using `pwd` (which is already modified on Windows to
> > output Windows paths).
> >
> > While fixing the new tests on Windows, we also have to exclude the tests
> > that want to write a file with a name that is illegal on Windows
> > (unfortunately, there is more than one test trying to make use of that
> > file).
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >  t/t1300-repo-config.sh | 15 ++++++++++++---
> >  1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
> > index 0236fe2..18eb769 100755
> > --- a/t/t1300-repo-config.sh
> > +++ b/t/t1300-repo-config.sh
> > @@ -1232,6 +1232,15 @@ test_expect_success 'set up --show-origin tests' '
> >  	EOF
> >  '
> >  
> > +if test_have_prereq MINGW
> > +then
> > +	# convert to Windows paths
> > +	HOME="$(pwd)"
> 
> We override HOME in t/test-lib.sh; shouldn't this be done there?
We override it with $PWD.

Remember, on Windows we have this funny situation where the shell, Perl, and the Unix tools used in scripting, know about POSIX paths, but little else. Most notably git.exe does *not* understand them [*1*].

The difference between $PWD and $(pwd) is, you guessed it, POSIX path vs Windows path, respectively. And since *some* of our tests verify shell/Perl scripts' correct behavior, we *want* $HOME to be a POSIX path, at least some of the time.

Show 10 quoted lines
> > +	INCLUDE_DIR="$HOME/include"
> 
> I am puzzled. 'set up --show-origin tests' do say INCLUDE_DIR is
> "$HOME/include" already, so why is this needed?
> 
> > +	export HOME INCLUDE_DIR
> 
> Existing tests use $INCLUDE_DIR (and $HOME) as shell variables just
> fine without exporting.  Why do these need to be exported only on
> MINGW?
Habit. The export is actually not needed at all, you are totally correct.
Show 5 quoted lines
> > +	git config -f .gitconfig include.path "$INCLUDE_DIR/absolute.include"
> > +fi
> 
> Perhaps if you adjust HOME before 'set up --show-origin tests' test,
> most (or all) of the above become unnecessary?

It did not even occur to me, thanks for that suggestion. It works perfectly. Will send out v2 in a moment.

Ciao, Dscho

Footnote [*1*]: we do have this hack, system_path(), that can turn "POSIX paths" into Windows paths. However, it actually turns paths relative to the prefix (as in "/usr/") into Windows paths, and the prefix is determined at runtime, from the location of git.exe. When the test suite runs, the location of git.exe is most definitely *not* related to any sensible prefix, therefore we simply cannot expect git.exe to handle POSIX paths correctly in the test suite.

Johannes Schindelin· Mar 22, 2016, 17:43 UTC · re: Johannes Schindelin · lore

[PATCH 4/4] mingw: skip some tests in t9115 due to file name issues

These two tests wanted to write file names which are incompatible with Windows' file naming rules.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t9115-git-svn-dcommit-funky-renames.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Show changes to t/t9115-git-svn-dcommit-funky-renames.sh +2 −2
diff --git a/t/t9115-git-svn-dcommit-funky-renames.sh b/t/t9115-git-svn-dcommit-funky-renames.sh
index 0990f8d..864395e 100755
--- a/t/t9115-git-svn-dcommit-funky-renames.sh
+++ b/t/t9115-git-svn-dcommit-funky-renames.sh
@@ -93,7 +93,7 @@ test_expect_success 'git svn rebase works inside a fresh-cloned repository' '
 # > to special UNICODE characters in the range 0xf000 to 0xf0ff (the
 # > "Private use area") when creating or accessing files.
 prepare_a_utf8_locale
-test_expect_success UTF8 'svn.pathnameencoding=cp932 new file on dcommit' '
+test_expect_success UTF8,!MINGW 'svn.pathnameencoding=cp932 new file on dcommit' '
 	LC_ALL=$a_utf8_locale &&
 	export LC_ALL &&
 	neq=$(printf "\201\202") &&
@@ -105,7 +105,7 @@ test_expect_success UTF8 'svn.pathnameencoding=cp932 new file on dcommit' '
 '
 
 # See the comment on the above test for setting of LC_ALL.
-test_expect_success 'svn.pathnameencoding=cp932 rename on dcommit' '
+test_expect_success !MINGW 'svn.pathnameencoding=cp932 rename on dcommit' '
 	LC_ALL=$a_utf8_locale &&
 	export LC_ALL &&
 	inf=$(printf "\201\207") &&
-- 
2.7.4.windows.1
Jonathan Nieder· Mar 22, 2016, 18:03 UTC · re: Johannes Schindelin · lore

Re: [PATCH 4/4] mingw: skip some tests in t9115 due to file name issues

Johannes Schindelin wrote:
> These two tests wanted to write file names which are incompatible with
> Windows' file naming rules.

Makes sense. Ideally these would use the FUNNYNAMES prereq which would be factored out as a lazy prereq from t3600, t4135, and t9903. But using !MINGW is simpler and works now.

Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Torsten Bögershausen· Mar 22, 2016, 18:30 UTC · re: Johannes Schindelin · lore

Re: [PATCH 4/4] mingw: skip some tests in t9115 due to file name issues

On 2016-03-22 18.43, Johannes Schindelin wrote:
> These two tests wanted to write file names which are incompatible with
> Windows' file naming rules.
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Is there a chance to squeeze in a precondition for HFS under Mac OS ?
> -test_expect_success UTF8 'svn.pathnameencoding=cp932 new file on dcommit' '
> +test_expect_success UTF8,!MINGW 'svn.pathnameencoding=cp932 new file on dcommit' '
+test_expect_success UTF8,!MINGW,!UTF8_NFD_TO_NFC
Show 9 quoted lines
>  	LC_ALL=$a_utf8_locale &&
>  	export LC_ALL &&
>  	neq=$(printf "\201\202") &&
> @@ -105,7 +105,7 @@ test_expect_success UTF8 'svn.pathnameencoding=cp932 new file on dcommit' '
>  '
>  
>  # See the comment on the above test for setting of LC_ALL.
> -test_expect_success 'svn.pathnameencoding=cp932 rename on dcommit' '
> +test_expect_success !MINGW 'svn.pathnameencoding=cp932 rename on dcommit' '
And the same protection for HFS here.
Question: Why do we need a UTF8 protection in #11, but not in #12 ?
I just tested t9115 under german cygwin, passes.
http://article.gmane.org/gmane.comp.version-control.git/288827
Junio C Hamano· Mar 22, 2016, 20:44 UTC · re: Torsten Bögershausen · lore

Re: [PATCH 4/4] mingw: skip some tests in t9115 due to file name issues

Torsten Bögershausen <tboegi@web.de> writes:
Show 7 quoted lines
> On 2016-03-22 18.43, Johannes Schindelin wrote:
>> These two tests wanted to write file names which are incompatible with
>> Windows' file naming rules.
>> 
>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Is there a chance to squeeze in a precondition for HFS under Mac OS ?
So you want this squashed into it?
 t/t9115-git-svn-dcommit-funky-renames.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Show changes to t/t9115-git-svn-dcommit-funky-renames.sh +2 −2
diff --git a/t/t9115-git-svn-dcommit-funky-renames.sh b/t/t9115-git-svn-dcommit-funky-renames.sh
index 864395e..a87d3d3 100755
--- a/t/t9115-git-svn-dcommit-funky-renames.sh
+++ b/t/t9115-git-svn-dcommit-funky-renames.sh
@@ -93,7 +93,7 @@ test_expect_success 'git svn rebase works inside a fresh-cloned repository' '
 # > to special UNICODE characters in the range 0xf000 to 0xf0ff (the
 # > "Private use area") when creating or accessing files.
 prepare_a_utf8_locale
-test_expect_success UTF8,!MINGW 'svn.pathnameencoding=cp932 new file on dcommit' '
+test_expect_success UTF8,!MINGW,!UTF8_NFD_TO_NFC 'svn.pathnameencoding=cp932 new file on dcommit' '
 	LC_ALL=$a_utf8_locale &&
 	export LC_ALL &&
 	neq=$(printf "\201\202") &&
@@ -105,7 +105,7 @@ test_expect_success UTF8,!MINGW 'svn.pathnameencoding=cp932 new file on dcommit'
 '
 
 # See the comment on the above test for setting of LC_ALL.
-test_expect_success !MINGW 'svn.pathnameencoding=cp932 rename on dcommit' '
+test_expect_success !MINGW,!UTF8_NFD_TO_NFC 'svn.pathnameencoding=cp932 rename on dcommit' '
 	LC_ALL=$a_utf8_locale &&
 	export LC_ALL &&
 	inf=$(printf "\201\207") &&
Torsten Bögershausen· Mar 22, 2016, 22:44 UTC · re: Junio C Hamano · lore

Re: [PATCH 4/4] mingw: skip some tests in t9115 due to file name issues

On 2016-03-22 21.44, Junio C Hamano wrote:
Show 11 quoted lines
> Torsten Bögershausen <tboegi@web.de> writes:
> 
>> On 2016-03-22 18.43, Johannes Schindelin wrote:
>>> These two tests wanted to write file names which are incompatible with
>>> Windows' file naming rules.
>>>
>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>
>> Is there a chance to squeeze in a precondition for HFS under Mac OS ?
> 
> So you want this squashed into it?
Yes, please.
Show 26 quoted lines
> 
>  t/t9115-git-svn-dcommit-funky-renames.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/t/t9115-git-svn-dcommit-funky-renames.sh b/t/t9115-git-svn-dcommit-funky-renames.sh
> index 864395e..a87d3d3 100755
> --- a/t/t9115-git-svn-dcommit-funky-renames.sh
> +++ b/t/t9115-git-svn-dcommit-funky-renames.sh
> @@ -93,7 +93,7 @@ test_expect_success 'git svn rebase works inside a fresh-cloned repository' '
>  # > to special UNICODE characters in the range 0xf000 to 0xf0ff (the
>  # > "Private use area") when creating or accessing files.
>  prepare_a_utf8_locale
> -test_expect_success UTF8,!MINGW 'svn.pathnameencoding=cp932 new file on dcommit' '
> +test_expect_success UTF8,!MINGW,!UTF8_NFD_TO_NFC 'svn.pathnameencoding=cp932 new file on dcommit' '
>  	LC_ALL=$a_utf8_locale &&
>  	export LC_ALL &&
>  	neq=$(printf "\201\202") &&
> @@ -105,7 +105,7 @@ test_expect_success UTF8,!MINGW 'svn.pathnameencoding=cp932 new file on dcommit'
>  '
>  
>  # See the comment on the above test for setting of LC_ALL.
> -test_expect_success !MINGW 'svn.pathnameencoding=cp932 rename on dcommit' '
> +test_expect_success !MINGW,!UTF8_NFD_TO_NFC 'svn.pathnameencoding=cp932 rename on dcommit' '
>  	LC_ALL=$a_utf8_locale &&
>  	export LC_ALL &&
>  	inf=$(printf "\201\207") &&
Junio C Hamano· Mar 22, 2016, 22:57 UTC · re: Torsten Bögershausen · lore

Re: [PATCH 4/4] mingw: skip some tests in t9115 due to file name issues

Torsten Bögershausen <tboegi@web.de> writes:
Show 13 quoted lines
> On 2016-03-22 21.44, Junio C Hamano wrote:
>> Torsten Bögershausen <tboegi@web.de> writes:
>> 
>>> On 2016-03-22 18.43, Johannes Schindelin wrote:
>>>> These two tests wanted to write file names which are incompatible with
>>>> Windows' file naming rules.
>>>>
>>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>>
>>> Is there a chance to squeeze in a precondition for HFS under Mac OS ?
>> 
>> So you want this squashed into it?
> Yes, please.

Dscho, I queued two out of these four, with a proposed fix-up patch for each of them, on 'pu'; but I won't squash them together myself without hearing from you as I do not test mingw or macosx.

Thanks.
Torsten Bögershausen· Mar 23, 2016, 05:54 UTC · re: Junio C Hamano · lore

Re: [PATCH 4/4] mingw: skip some tests in t9115 due to file name issues

On 2016-03-22 23.57, Junio C Hamano wrote:
Show 5 quoted lines
> Dscho, I queued two out of these four, with a proposed fix-up patch
> for each of them, on 'pu'; but I won't squash them together myself
> without hearing from you as I do not test mingw or macosx.
> 
> Thanks.
the queued t9115 passes under Mac OS X (#11 and #12 are skipped as expected)

---------------- Beside that, do we want to amend the commit message like this:

Author: Johannes Schindelin <johannes.schindelin@gmx.de>
Date:   Tue Mar 22 18:43:00 2016 +0100
    skip some tests in t9115 due to file name issues
    These two tests wanted to write file names which work under Linux or
    CYGWIN, but are incompatible with file naming rules under mingw or HFS.
    Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
    Signed-off-by: Torsten Bögershausen <tboegi@web.de>
    Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
----------------
http://thread.gmane.org/gmane.comp.version-control.git/285776/focus=287717
Johannes Schindelin· Mar 23, 2016, 10:49 UTC · re: Torsten Bögershausen · lore

Re: [PATCH 4/4] mingw: skip some tests in t9115 due to file name issues

Hi Junio & Torsten,
On Wed, 23 Mar 2016, Torsten Bögershausen wrote:
> On 2016-03-22 23.57, Junio C Hamano wrote:
> > Dscho, I queued two out of these four, with a proposed fix-up patch
> > for each of them, on 'pu'; but I won't squash them together myself
> > without hearing from you as I do not test mingw or macosx.
The suggested changes will be squashed into v2.
Show 14 quoted lines
> Beside that, do we want to amend the commit message like this:
> 
> Author: Johannes Schindelin <johannes.schindelin@gmx.de>
> Date:   Tue Mar 22 18:43:00 2016 +0100
> 
>     skip some tests in t9115 due to file name issues
> 
>     These two tests wanted to write file names which work under Linux or
>     CYGWIN, but are incompatible with file naming rules under mingw or HFS.
> 
>     Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>     Signed-off-by: Torsten Bögershausen <tboegi@web.de>
>     Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
>     Signed-off-by: Junio C Hamano <gitster@pobox.com>

Thanks, I used a slightly different version, as I had crafted it before reading this mail already.

Ciao, Dscho

Junio C Hamano· Mar 23, 2016, 15:56 UTC · re: Johannes Schindelin · lore

Re: [PATCH 4/4] mingw: skip some tests in t9115 due to file name issues

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 28 quoted lines
> Hi Junio & Torsten,
>
> On Wed, 23 Mar 2016, Torsten Bögershausen wrote:
>
>> On 2016-03-22 23.57, Junio C Hamano wrote:
>> > Dscho, I queued two out of these four, with a proposed fix-up patch
>> > for each of them, on 'pu'; but I won't squash them together myself
>> > without hearing from you as I do not test mingw or macosx.
>
> The suggested changes will be squashed into v2.
>
>> Beside that, do we want to amend the commit message like this:
>> 
>> Author: Johannes Schindelin <johannes.schindelin@gmx.de>
>> Date:   Tue Mar 22 18:43:00 2016 +0100
>> 
>>     skip some tests in t9115 due to file name issues
>> 
>>     These two tests wanted to write file names which work under Linux or
>>     CYGWIN, but are incompatible with file naming rules under mingw or HFS.
>> 
>>     Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>     Signed-off-by: Torsten Bögershausen <tboegi@web.de>
>>     Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
>>     Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> Thanks, I used a slightly different version, as I had crafted it before
> reading this mail already.
Thanks; Torsten, sorry but could you do another round of check, please?
Torsten Bögershausen· Mar 23, 2016, 19:08 UTC · re: Junio C Hamano · lore

Re: [PATCH 4/4] mingw: skip some tests in t9115 due to file name issues

On 2016-03-23 16.56, Junio C Hamano wrote:
>> Thanks, I used a slightly different version, as I had crafted it before
>> reading this mail already.
> 
> Thanks; Torsten, sorry but could you do another round of check, please?
Sure :-)
Junio C Hamano· Mar 22, 2016, 17:50 UTC · re: Johannes Schindelin · lore

Re: [PATCH 0/4] Git for Windows fixes in preparation for 2.8.0

Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> The t1300 and t9115 tests regressed on Windows. These patches fix that.

Thanks, it might be probably too late for 2.8.0 final to do back-and-forth reviews, but lets see how it goes.

Show 13 quoted lines
>
>
> Johannes Schindelin (4):
>   config --show-origin: report paths with forward slashes
>   Make t1300-repo-config resilient to being run via 'sh -x'
>   t1300: fix the new --show-origin tests on Windows
>   mingw: skip some tests in t9115 due to file name issues
>
>  compat/mingw.h                           |  6 ++++++
>  path.c                                   |  3 +++
>  t/t1300-repo-config.sh                   | 23 ++++++++++++++---------
>  t/t9115-git-svn-dcommit-funky-renames.sh |  4 ++--
>  4 files changed, 25 insertions(+), 11 deletions(-)
Johannes Schindelin· Mar 23, 2016, 10:54 UTC · re: Johannes Schindelin · lore

[PATCH v2 0/4] Git for Windows fixes in preparation for 2.8.0

The t1300 and t9115 tests regressed on Windows. These patches fix that.
Johannes Schindelin (4):
  config --show-origin: report paths with forward slashes
  Make t1300-repo-config resilient to being run via 'sh -x'
  t1300: fix the new --show-origin tests on Windows
  mingw: skip some tests in t9115 due to file name issues
 compat/mingw.h                           |  6 ++++++
 path.c                                   |  3 +++
 t/t1300-repo-config.sh                   | 18 +++++++++---------
 t/t9115-git-svn-dcommit-funky-renames.sh |  4 ++--
 4 files changed, 20 insertions(+), 11 deletions(-)
Interdiff vs v1:
 diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
 index 18eb769..a37ebb2 100755
 --- a/t/t1300-repo-config.sh
 +++ b/t/t1300-repo-config.sh
 @@ -700,12 +700,12 @@ test_expect_success 'invalid unit' '
  	git config aninvalid.unit >actual &&
  	test_cmp expect actual &&
  	test_must_fail git config --int --get aninvalid.unit 2>actual &&
 -	grep "^fatal: bad numeric config value .1auto. for .aninvalid.unit. in file .git/config: invalid unit$" actual
 +	test_i18ngrep "bad numeric config value .1auto. for .aninvalid.unit. in file .git/config: invalid unit" actual
  '
  
  test_expect_success 'invalid stdin config' '
  	echo "[broken" | test_must_fail git config --list --file - >output 2>&1 &&
 -	grep "^fatal: bad config line 1 in standard input $" output
 +	test_i18ngrep "bad config line 1 in standard input" output
  '
  
  cat > expect << EOF
 @@ -1205,6 +1205,9 @@ test_expect_success POSIXPERM,PERL 'preserves existing permissions' '
  	  "die q(badrename) if ((stat(q(.git/config)))[2] & 07777) != 0600"
  '
  
 +! test_have_prereq MINGW ||
 +HOME="$(pwd)" # convert to Windows path
 +
  test_expect_success 'set up --show-origin tests' '
  	INCLUDE_DIR="$HOME/include" &&
  	mkdir -p "$INCLUDE_DIR" &&
 @@ -1232,14 +1235,6 @@ test_expect_success 'set up --show-origin tests' '
  	EOF
  '
  
 -if test_have_prereq MINGW
 -then
 -	# convert to Windows paths
 -	HOME="$(pwd)"
 -	INCLUDE_DIR="$HOME/include"
 -	export HOME INCLUDE_DIR
 -	git config -f .gitconfig include.path "$INCLUDE_DIR/absolute.include"
 -fi
  
  test_expect_success '--show-origin with --list' '
  	cat >expect <<-EOF &&
 diff --git a/t/t9115-git-svn-dcommit-funky-renames.sh b/t/t9115-git-svn-dcommit-funky-renames.sh
 index 864395e..a87d3d3 100755
 --- a/t/t9115-git-svn-dcommit-funky-renames.sh
 +++ b/t/t9115-git-svn-dcommit-funky-renames.sh
 @@ -93,7 +93,7 @@ test_expect_success 'git svn rebase works inside a fresh-cloned repository' '
  # > to special UNICODE characters in the range 0xf000 to 0xf0ff (the
  # > "Private use area") when creating or accessing files.
  prepare_a_utf8_locale
 -test_expect_success UTF8,!MINGW 'svn.pathnameencoding=cp932 new file on dcommit' '
 +test_expect_success UTF8,!MINGW,!UTF8_NFD_TO_NFC 'svn.pathnameencoding=cp932 new file on dcommit' '
  	LC_ALL=$a_utf8_locale &&
  	export LC_ALL &&
  	neq=$(printf "\201\202") &&
 @@ -105,7 +105,7 @@ test_expect_success UTF8,!MINGW 'svn.pathnameencoding=cp932 new file on dcommit'
  '
  
  # See the comment on the above test for setting of LC_ALL.
 -test_expect_success !MINGW 'svn.pathnameencoding=cp932 rename on dcommit' '
 +test_expect_success !MINGW,!UTF8_NFD_TO_NFC 'svn.pathnameencoding=cp932 rename on dcommit' '
  	LC_ALL=$a_utf8_locale &&
  	export LC_ALL &&
  	inf=$(printf "\201\207") &&
-- 
2.7.4.windows.1
Johannes Schindelin· Mar 23, 2016, 10:55 UTC · re: Johannes Schindelin · lore

[PATCH v2 1/4] config --show-origin: report paths with forward slashes

On Windows, the backslash is the native directory separator, but all supported Windows versions also accept the forward slash in most circumstances.

Our tests expect forward slashes.
Relative paths are generated by Git using forward slashes.

So let's try to be consistent and use forward slashes in the $HOME part of the paths reported by `git config --show-origin`, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 compat/mingw.h | 6 ++++++
 path.c         | 3 +++
 2 files changed, 9 insertions(+)
Show changes to 2 files +9 −0

compat/mingw.h, path.c

diff --git a/compat/mingw.h b/compat/mingw.h
index 8c5bf50..c008694 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -396,6 +396,12 @@ static inline char *mingw_find_last_dir_sep(const char *path)
 			ret = (char *)path;
 	return ret;
 }
+static inline void convert_slashes(char *path)
+{
+	for (; *path; path++)
+		if (*path == '\\')
+			*path = '/';
+}
 #define find_last_dir_sep mingw_find_last_dir_sep
 int mingw_offset_1st_component(const char *path);
 #define offset_1st_component mingw_offset_1st_component
diff --git a/path.c b/path.c
index 8b7e168..969b494 100644
--- a/path.c
+++ b/path.c
@@ -584,6 +584,9 @@ char *expand_user_path(const char *path)
 			if (!home)
 				goto return_null;
 			strbuf_addstr(&user_path, home);
+#ifdef GIT_WINDOWS_NATIVE
+			convert_slashes(user_path.buf);
+#endif
 		} else {
 			struct passwd *pw = getpw_str(username, username_len);
 			if (!pw)
-- 
2.7.4.windows.1
Johannes Schindelin· Mar 23, 2016, 10:55 UTC · re: Johannes Schindelin · lore

[PATCH v2 2/4] Make t1300-repo-config resilient to being run via 'sh -x'

One of this developer's primary tools to diagnose broken regression tests is to run the test script using 'sh -x t... -i -v' to find out *which* call *actually* demonstrates the symptom.

Hence it is pretty counterproductive if the test script behaves differently when being run via 'sh -x', in particular when using test_cmp or test_i18ncmp on redirected stderr.

So let's use test_i18ngrep (as suggested by Jonathan Nieder) instead of test_cmp/test_i18ncmp to verify that stderr looks as expected.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1300-repo-config.sh | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)
Show changes to t/t1300-repo-config.sh +2 −6
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 8867ce1..dca27a3 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -699,17 +699,13 @@ test_expect_success 'invalid unit' '
 	echo 1auto >expect &&
 	git config aninvalid.unit >actual &&
 	test_cmp expect actual &&
-	cat >expect <<-\EOF &&
-	fatal: bad numeric config value '\''1auto'\'' for '\''aninvalid.unit'\'' in file .git/config: invalid unit
-	EOF
 	test_must_fail git config --int --get aninvalid.unit 2>actual &&
-	test_i18ncmp expect actual
+	test_i18ngrep "bad numeric config value .1auto. for .aninvalid.unit. in file .git/config: invalid unit" actual
 '
 
 test_expect_success 'invalid stdin config' '
-	echo "fatal: bad config line 1 in standard input " >expect &&
 	echo "[broken" | test_must_fail git config --list --file - >output 2>&1 &&
-	test_cmp expect output
+	test_i18ngrep "bad config line 1 in standard input" output
 '
 
 cat > expect << EOF
-- 
2.7.4.windows.1
Johannes Schindelin· Mar 23, 2016, 10:55 UTC · re: Johannes Schindelin · lore

[PATCH v2 3/4] t1300: fix the new --show-origin tests on Windows

On Windows, we have that funny situation where the test script can refer to POSIX paths because it runs in a shell that uses a POSIX emulation layer ("MSYS2 runtime"). Yet, git.exe does *not* understand POSIX paths at all but only pure Windows paths.

So let's just convert the POSIX paths to Windows paths before passing them on to Git, using `pwd` (which is already modified on Windows to output Windows paths).

While fixing the new tests on Windows, we also have to exclude the tests that want to write a file with a name that is illegal on Windows (unfortunately, there is more than one test trying to make use of that file).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 t/t1300-repo-config.sh | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)
Show changes to t/t1300-repo-config.sh +7 −3
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index dca27a3..a37ebb2 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -1205,6 +1205,9 @@ test_expect_success POSIXPERM,PERL 'preserves existing permissions' '
 	  "die q(badrename) if ((stat(q(.git/config)))[2] & 07777) != 0600"
 '
 
+! test_have_prereq MINGW ||
+HOME="$(pwd)" # convert to Windows path
+
 test_expect_success 'set up --show-origin tests' '
 	INCLUDE_DIR="$HOME/include" &&
 	mkdir -p "$INCLUDE_DIR" &&
@@ -1232,6 +1235,7 @@ test_expect_success 'set up --show-origin tests' '
 	EOF
 '
 
+
 test_expect_success '--show-origin with --list' '
 	cat >expect <<-EOF &&
 		file:$HOME/.gitconfig	user.global=true
@@ -1304,7 +1308,7 @@ test_expect_success 'set up custom config file' '
 	EOF
 '
 
-test_expect_success '--show-origin escape special file name characters' '
+test_expect_success !MINGW '--show-origin escape special file name characters' '
 	cat >expect <<-\EOF &&
 		file:"file\" (dq) and spaces.conf"	user.custom=true
 	EOF
@@ -1333,7 +1337,7 @@ test_expect_success '--show-origin stdin with file include' '
 	test_cmp expect output
 '
 
-test_expect_success '--show-origin blob' '
+test_expect_success !MINGW '--show-origin blob' '
 	cat >expect <<-\EOF &&
 		blob:a9d9f9e555b5c6f07cbe09d3f06fe3df11e09c08	user.custom=true
 	EOF
@@ -1342,7 +1346,7 @@ test_expect_success '--show-origin blob' '
 	test_cmp expect output
 '
 
-test_expect_success '--show-origin blob ref' '
+test_expect_success !MINGW '--show-origin blob ref' '
 	cat >expect <<-\EOF &&
 		blob:"master:file\" (dq) and spaces.conf"	user.custom=true
 	EOF
-- 
2.7.4.windows.1
Lars Schneider· Mar 23, 2016, 11:08 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2 3/4] t1300: fix the new --show-origin tests on Windows

On 23 Mar 2016, at 11:55, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:
Show 13 quoted lines
> On Windows, we have that funny situation where the test script can refer
> to POSIX paths because it runs in a shell that uses a POSIX emulation
> layer ("MSYS2 runtime"). Yet, git.exe does *not* understand POSIX paths
> at all but only pure Windows paths.
> 
> So let's just convert the POSIX paths to Windows paths before passing
> them on to Git, using `pwd` (which is already modified on Windows to
> output Windows paths).
> 
> While fixing the new tests on Windows, we also have to exclude the tests
> that want to write a file with a name that is illegal on Windows
> (unfortunately, there is more than one test trying to make use of that
> file).

Thanks for these Windows fixes! After the 2.8 release I will try to post a patch that uses a different filename where possible.

Cheers, Lars

Show 59 quoted lines
> 
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> t/t1300-repo-config.sh | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
> index dca27a3..a37ebb2 100755
> --- a/t/t1300-repo-config.sh
> +++ b/t/t1300-repo-config.sh
> @@ -1205,6 +1205,9 @@ test_expect_success POSIXPERM,PERL 'preserves existing permissions' '
> 	  "die q(badrename) if ((stat(q(.git/config)))[2] & 07777) != 0600"
> '
> 
> +! test_have_prereq MINGW ||
> +HOME="$(pwd)" # convert to Windows path
> +
> test_expect_success 'set up --show-origin tests' '
> 	INCLUDE_DIR="$HOME/include" &&
> 	mkdir -p "$INCLUDE_DIR" &&
> @@ -1232,6 +1235,7 @@ test_expect_success 'set up --show-origin tests' '
> 	EOF
> '
> 
> +
> test_expect_success '--show-origin with --list' '
> 	cat >expect <<-EOF &&
> 		file:$HOME/.gitconfig	user.global=true
> @@ -1304,7 +1308,7 @@ test_expect_success 'set up custom config file' '
> 	EOF
> '
> 
> -test_expect_success '--show-origin escape special file name characters' '
> +test_expect_success !MINGW '--show-origin escape special file name characters' '
> 	cat >expect <<-\EOF &&
> 		file:"file\" (dq) and spaces.conf"	user.custom=true
> 	EOF
> @@ -1333,7 +1337,7 @@ test_expect_success '--show-origin stdin with file include' '
> 	test_cmp expect output
> '
> 
> -test_expect_success '--show-origin blob' '
> +test_expect_success !MINGW '--show-origin blob' '
> 	cat >expect <<-\EOF &&
> 		blob:a9d9f9e555b5c6f07cbe09d3f06fe3df11e09c08	user.custom=true
> 	EOF
> @@ -1342,7 +1346,7 @@ test_expect_success '--show-origin blob' '
> 	test_cmp expect output
> '
> 
> -test_expect_success '--show-origin blob ref' '
> +test_expect_success !MINGW '--show-origin blob ref' '
> 	cat >expect <<-\EOF &&
> 		blob:"master:file\" (dq) and spaces.conf"	user.custom=true
> 	EOF
> -- 
> 2.7.4.windows.1
> 
> 
Johannes Schindelin· Mar 23, 2016, 10:55 UTC · re: Johannes Schindelin · lore

[PATCH v2 4/4] mingw: skip some tests in t9115 due to file name issues

These two tests wanted to write file names which are incompatible with Windows' file naming rules (even if they pass using Cygwin due to Cygwin's magic path mangling).

While at it, skip the same tests also on MacOSX/HFS, as pointed out by Torsten Bögershausen.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t9115-git-svn-dcommit-funky-renames.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Show changes to t/t9115-git-svn-dcommit-funky-renames.sh +2 −2
diff --git a/t/t9115-git-svn-dcommit-funky-renames.sh b/t/t9115-git-svn-dcommit-funky-renames.sh
index 0990f8d..a87d3d3 100755
--- a/t/t9115-git-svn-dcommit-funky-renames.sh
+++ b/t/t9115-git-svn-dcommit-funky-renames.sh
@@ -93,7 +93,7 @@ test_expect_success 'git svn rebase works inside a fresh-cloned repository' '
 # > to special UNICODE characters in the range 0xf000 to 0xf0ff (the
 # > "Private use area") when creating or accessing files.
 prepare_a_utf8_locale
-test_expect_success UTF8 'svn.pathnameencoding=cp932 new file on dcommit' '
+test_expect_success UTF8,!MINGW,!UTF8_NFD_TO_NFC 'svn.pathnameencoding=cp932 new file on dcommit' '
 	LC_ALL=$a_utf8_locale &&
 	export LC_ALL &&
 	neq=$(printf "\201\202") &&
@@ -105,7 +105,7 @@ test_expect_success UTF8 'svn.pathnameencoding=cp932 new file on dcommit' '
 '
 
 # See the comment on the above test for setting of LC_ALL.
-test_expect_success 'svn.pathnameencoding=cp932 rename on dcommit' '
+test_expect_success !MINGW,!UTF8_NFD_TO_NFC 'svn.pathnameencoding=cp932 rename on dcommit' '
 	LC_ALL=$a_utf8_locale &&
 	export LC_ALL &&
 	inf=$(printf "\201\207") &&
-- 
2.7.4.windows.1

← back to recent threads