threads / patch / 41188

patcht0060: loosen overly strict expectations

Subject: [PATCH] t0060: loosen overly strict expectations

## tl;dr

13 messages between Jan 14, 2016 and Jan 19, 2016. Diffs are folded; open one to read it.

replies: 12people: 5as markdown or json

Johannes Schindelin· Jan 14, 2016, 06:48 UTC · lore

The dirname() tests file were developed and tested on only the five platforms available to the developer at the time, namely: Linux (both 32 and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html (i.e. the POSIX spec) says, in part:

	If the string pointed to by path consists entirely of the '/'
	character, basename() shall return a pointer to the string "/".
	If the string pointed to by path is exactly "//", it is
	implementation-defined whether "/" or "//" is returned.

The thinking behind testing precise, OS-dependent output values was to document that different setups produce different values. However, as the test failures on MacOSX illustrated eloquently: hardcoding pretty much each and every setup's expectations is pretty fragile.

This is not limited to the "//" vs "/" case, of course, other inputs are also allowed to produce multiple outpus by the POSIX specs.

So let's just test for all allowed values and be done with it. This still documents that Git cannot rely on one particular output value in those cases, so the intention of the original tests is still met.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
	This is the promised fix.
 test-path-utils.c | 78 +++++++++++++++----------------------------------------
 1 file changed, 21 insertions(+), 57 deletions(-)
Show changes to test-path-utils.c +21 −57
diff --git a/test-path-utils.c b/test-path-utils.c
index 4ab68ac..c3adcd8 100644
--- a/test-path-utils.c
+++ b/test-path-utils.c
@@ -42,6 +42,7 @@ static void normalize_argv_string(const char **var, const char *input)
 struct test_data {
 	const char *from;  /* input:  transform from this ... */
 	const char *to;    /* output: ... to this.            */
+	const char *alternative; /* output: ... or this.      */
 };
 
 static int test_function(struct test_data *data, char *(*func)(char *input),
@@ -58,11 +59,18 @@ static int test_function(struct test_data *data, char *(*func)(char *input),
 			strcpy(buffer, data[i].from);
 			to = func(buffer);
 		}
-		if (strcmp(to, data[i].to)) {
+		if (!strcmp(to, data[i].to))
+			continue;
+		if (!data[i].alternative)
 			error("FAIL: %s(%s) => '%s' != '%s'\n",
 				funcname, data[i].from, to, data[i].to);
-			failed = 1;
-		}
+		else if (!strcmp(to, data[i].alternative))
+			continue;
+		else
+			error("FAIL: %s(%s) => '%s' != '%s', '%s'\n",
+				funcname, data[i].from, to, data[i].to,
+				data[i].alternative);
+		failed = 1;
 	}
 	return failed;
 }
@@ -74,15 +82,9 @@ static struct test_data basename_data[] = {
 	{ ".",               "."    },
 	{ "..",              ".."   },
 	{ "/",               "/"    },
-#if defined(__CYGWIN__) && !defined(NO_LIBGEN_H)
-	{ "//",              "//"   },
-	{ "///",             "//"   },
-	{ "////",            "//"   },
-#else
-	{ "//",              "/"    },
-	{ "///",             "/"    },
-	{ "////",            "/"    },
-#endif
+	{ "//",              "/", "//" },
+	{ "///",             "/", "//" },
+	{ "////",            "/", "//" },
 	{ "usr",             "usr"  },
 	{ "/usr",            "usr"  },
 	{ "/usr/",           "usr"  },
@@ -92,7 +94,6 @@ static struct test_data basename_data[] = {
 	{ "usr/lib///",      "lib"  },
 
 #if defined(__MINGW32__) || defined(_MSC_VER)
-
 	/* --- win32 type paths --- */
 	{ "\\usr",           "usr"  },
 	{ "\\usr\\",         "usr"  },
@@ -111,26 +112,9 @@ static struct test_data basename_data[] = {
 	{ "C:a",             "a"    },
 	{ "C:/",             "/"    },
 	{ "C:///",           "/"    },
-#if defined(NO_LIBGEN_H)
-	{ "\\",              "\\"   },
-	{ "\\\\",            "\\"   },
-	{ "\\\\\\",          "\\"   },
-#else
-
-	/* win32 platform variations: */
-#if defined(__MINGW32__)
-	{ "\\",              "/"    },
-	{ "\\\\",            "/"    },
-	{ "\\\\\\",          "/"    },
-#endif
-
-#if defined(_MSC_VER)
-	{ "\\",              "\\"   },
-	{ "\\\\",            "\\"   },
-	{ "\\\\\\",          "\\"   },
-#endif
-
-#endif
+	{ "\\",              "\\", "/" },
+	{ "\\\\",            "\\", "/" },
+	{ "\\\\\\",          "\\", "/" },
 #endif
 	{ NULL,              NULL   }
 };
@@ -142,14 +126,9 @@ static struct test_data dirname_data[] = {
 	{ ".",               "."      },
 	{ "..",              "."      },
 	{ "/",               "/"      },
-	{ "//",              "//"     },
-#if defined(__CYGWIN__) && !defined(NO_LIBGEN_H)
-	{ "///",             "//"     },
-	{ "////",            "//"     },
-#else
-	{ "///",             "/"      },
-	{ "////",            "/"      },
-#endif
+	{ "//",              "/", "//" },
+	{ "///",             "/", "//" },
+	{ "////",            "/", "//" },
 	{ "usr",             "."      },
 	{ "/usr",            "/"      },
 	{ "/usr/",           "/"      },
@@ -159,7 +138,6 @@ static struct test_data dirname_data[] = {
 	{ "usr/lib///",      "usr"    },
 
 #if defined(__MINGW32__) || defined(_MSC_VER)
-
 	/* --- win32 type paths --- */
 	{ "\\",              "\\"     },
 	{ "\\\\",            "\\\\"   },
@@ -180,21 +158,7 @@ static struct test_data dirname_data[] = {
 	{ "C:usr/lib///",    "C:usr"  },
 	{ "\\\\\\",          "\\"     },
 	{ "\\\\\\\\",        "\\"     },
-#if defined(NO_LIBGEN_H)
-	{ "C:",              "C:."    },
-#else
-
-	/* win32 platform variations: */
-#if defined(__MINGW32__)
-	/* the following is clearly wrong ... */
-	{ "C:",              "."      },
-#endif
-
-#if defined(_MSC_VER)
-	{ "C:",              "C:."    },
-#endif
-
-#endif
+	{ "C:",              "C:.", "." },
 #endif
 	{ NULL,              NULL     }
 };
-- 
2.6.3.windows.1.300.g1c25e49
Junio C Hamano· Jan 14, 2016, 17:33 UTC · re: Johannes Schindelin · lore

Re: [PATCH] t0060: loosen overly strict expectations

Johannes Schindelin <johannes.schindelin@gmx.de> writes:
Show 26 quoted lines
> The dirname() tests file were developed and tested on only the five
> platforms available to the developer at the time, namely: Linux (both 32
> and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
> (i.e. the POSIX spec) says, in part:
>
> 	If the string pointed to by path consists entirely of the '/'
> 	character, basename() shall return a pointer to the string "/".
> 	If the string pointed to by path is exactly "//", it is
> 	implementation-defined whether "/" or "//" is returned.
>
> The thinking behind testing precise, OS-dependent output values was to
> document that different setups produce different values. However, as the
> test failures on MacOSX illustrated eloquently: hardcoding pretty much each
> and every setup's expectations is pretty fragile.
>
> This is not limited to the "//" vs "/" case, of course, other inputs are
> also allowed to produce multiple outpus by the POSIX specs.
>
> So let's just test for all allowed values and be done with it. This still
> documents that Git cannot rely on one particular output value in those
> cases, so the intention of the original tests is still met.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
Sounds sensible.  Thanks.

This is not a problem with this patch, but the resulting basename_data[] array seems to test "C:/usr" going to "usr" twice under _MSC_VER or __MINGW32__.

Also...
Show 12 quoted lines
> -#if defined(__MINGW32__)
> -	/* the following is clearly wrong ... */
> -	{ "C:",              "."      },
> -#endif
> -
> -#if defined(_MSC_VER)
> -	{ "C:",              "C:."    },
> -#endif
> -
> -#endif
> +	{ "C:",              "C:.", "." },
>  #endif

"C:" is still allowed to go to "."; is it still "clearly wrong", or do we have a reason why we think it is not wrong at all?

I think the comment was written by Ramsay and also suspect that you did not specifically agree or disagree with that particular decision, so I'd understand if you do not have a strong opinion either way, but I'd like to hear from Ramsay. Perhaps earlier we thought it was clearly wrong but we no longer do?

Ramsay Jones· Jan 14, 2016, 18:13 UTC · re: Junio C Hamano · lore

Re: [PATCH] t0060: loosen overly strict expectations

On 14/01/16 17:33, Junio C Hamano wrote:
Show 26 quoted lines
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> Also...
> 
>> -#if defined(__MINGW32__)
>> -	/* the following is clearly wrong ... */
>> -	{ "C:",              "."      },
>> -#endif
>> -
>> -#if defined(_MSC_VER)
>> -	{ "C:",              "C:."    },
>> -#endif
>> -
>> -#endif
>> +	{ "C:",              "C:.", "." },
>>  #endif
> 
> "C:" is still allowed to go to "."; is it still "clearly wrong",
> or do we have a reason why we think it is not wrong at all?
> 
> I think the comment was written by Ramsay and also suspect that you
> did not specifically agree or disagree with that particular
> decision, so I'd understand if you do not have a strong opinion
> either way, but I'd like to hear from Ramsay.  Perhaps earlier we
> thought it was clearly wrong but we no longer do?
> 

Yes, that comment was mine. The result is "clearly wrong" if you follow the POSIX rules [1], but that may not translate exactly to a dos like path. ;-)

I think the question is: does it make a difference if you call chdir() on the result? Which brings up something which I have been ignoring. Correct me if I'm wrong (quite possible), but _each_ drive has a current working directory associated with it in win32, so it's a bit difficult to use drive designators with a relative path (eg. C:usr/lib).

Note: The test data in the test-libgen.c file was using Linux
as the 'benchmark' for the POSIX paths and IIRC MinGW-32 for
the dos paths. (Note that I said 'benchmark' _not_ 'correct'). :-P

ATB, Ramsay Jones

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html
Johannes Sixt· Jan 14, 2016, 22:14 UTC · re: Ramsay Jones · lore

Re: [PATCH] t0060: loosen overly strict expectations

Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
> Correct me if I'm wrong (quite possible), but
> _each_ drive has a current working directory associated with
> it in win32, so it's a bit difficult to use drive designators
> with a relative path (eg. C:usr/lib).

As far as it matters for Git, such a path is still an absolute path, because it is not anchored at $(pwd).

-- Hannes
Ramsay Jones· Jan 15, 2016, 00:46 UTC · re: Johannes Sixt · lore

Re: [PATCH] t0060: loosen overly strict expectations

On 14/01/16 22:14, Johannes Sixt wrote:
Show 8 quoted lines
> Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
>> Correct me if I'm wrong (quite possible), but
>> _each_ drive has a current working directory associated with
>> it in win32, so it's a bit difficult to use drive designators
>> with a relative path (eg. C:usr/lib).
> 
> As far as it matters for Git, such a path is still an absolute path, 
> because it is not anchored at $(pwd).

I have been using cygwin on windows since beta-18 (about 1995), in order to avoid most of the horrors of the windows command line, so I'm a little rusty. ;-)

You know windows _much_ better than me, so could you please educate me on this point. I tried this (on windows 8.1):

    ramsay@satellite $ cmd
    Microsoft Windows [Version 6.3.9600]
    (c) 2013 Microsoft Corporation. All rights reserved.
    
    C:\cygwin64\home\ramsay>cd junk
    cd junk
    
    C:\cygwin64\home\ramsay\junk>dir
    dir
     Volume in drive C is TI31255200A
     Volume Serial Number is 0024-4AC0
    
     Directory of C:\cygwin64\home\ramsay\junk
    
    15/01/2016  00:23    <DIR>          .
    15/01/2016  00:23    <DIR>          ..
    15/01/2016  00:23                 1 regular
    15/01/2016  00:23    <DIR>          sub-1
    15/01/2016  00:24    <DIR>          sub-2
                   1 File(s)              1 bytes
                   4 Dir(s)  800,988,291,072 bytes free
    
    C:\cygwin64\home\ramsay\junk>dir C:
    dir C:
     Volume in drive C is TI31255200A
     Volume Serial Number is 0024-4AC0
    
     Directory of C:\cygwin64\home\ramsay\junk
    
    15/01/2016  00:23    <DIR>          .
    15/01/2016  00:23    <DIR>          ..
    15/01/2016  00:23                 1 regular
    15/01/2016  00:23    <DIR>          sub-1
    15/01/2016  00:24    <DIR>          sub-2
                   1 File(s)              1 bytes
                   4 Dir(s)  800,988,291,072 bytes free
    
    C:\cygwin64\home\ramsay\junk>dir C:.
    dir C:.
     Volume in drive C is TI31255200A
     Volume Serial Number is 0024-4AC0
    
     Directory of C:\cygwin64\home\ramsay\junk
    
    15/01/2016  00:23    <DIR>          .
    15/01/2016  00:23    <DIR>          ..
    15/01/2016  00:23                 1 regular
    15/01/2016  00:23    <DIR>          sub-1
    15/01/2016  00:24    <DIR>          sub-2
                   1 File(s)              1 bytes
                   4 Dir(s)  800,988,291,072 bytes free
    
    C:\cygwin64\home\ramsay\junk>dir C:\
    dir C:\
     Volume in drive C is TI31255200A
     Volume Serial Number is 0024-4AC0
    
     Directory of C:\
    
    17/09/2015  15:52    <DIR>          cygwin64
    05/08/2015  10:10               383 ftconfig.ini
    09/04/2014  05:41    <DIR>          Intel
    22/08/2013  15:22    <DIR>          PerfLogs
    06/10/2015  19:28    <DIR>          Program Files
    26/12/2015  14:09    <DIR>          Program Files (x86)
    18/05/2014  11:18                 0 Recovery.txt
    03/12/2013  17:02    <DIR>          Toshiba
    25/06/2014  18:15    <DIR>          UBIOS
    26/12/2015  14:09    <DIR>          Users
    27/08/2015  10:08    <DIR>          Windows
                   2 File(s)            383 bytes
                   9 Dir(s)  800,988,299,264 bytes free
    
    C:\cygwin64\home\ramsay\junk>dir C:sub-1
    dir C:sub-1
     Volume in drive C is TI31255200A
     Volume Serial Number is 0024-4AC0
    
     Directory of C:\cygwin64\home\ramsay\junk\sub-1
    
    15/01/2016  00:23    <DIR>          .
    15/01/2016  00:23    <DIR>          ..
    15/01/2016  00:23                 1 bill
    15/01/2016  00:23                 1 fred
                   2 File(s)              2 bytes
                   2 Dir(s)  800,988,299,264 bytes free
    
    C:\cygwin64\home\ramsay\junk>exit
    exit
    ramsay@satellite $ 
... which seems to contradict what you say above.
What am I missing?

ATB, Ramsay Jones

    
Johannes Schindelin· Jan 15, 2016, 06:34 UTC · re: Ramsay Jones · lore

Re: [PATCH] t0060: loosen overly strict expectations

Hi Ramsay,
On Fri, 15 Jan 2016, Ramsay Jones wrote:
Show 13 quoted lines
> On 14/01/16 22:14, Johannes Sixt wrote:
> > Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
> >> Correct me if I'm wrong (quite possible), but _each_ drive has a
> >> current working directory associated with it in win32, so it's a bit
> >> difficult to use drive designators with a relative path (eg.
> >> C:usr/lib).
> > 
> > As far as it matters for Git, such a path is still an absolute path,
> > because it is not anchored at $(pwd).
> 
> [...] seems to contradict what you say above.
> 
> What am I missing?

The missing bit is: while C:usr/lib is *not* anchored on $(pwd), it is *still* not an absolute path because it is anchored on the current directory of the C: drive (the entire idea that some drive state can change the meaning of "C:usr/lib" makes it a non-absolute one).

Since this concept -- a path that is neither relative to $(pwd) nor absolute -- does not exist on Linux, I do not think that Git for Windows handles this case well at all.

Ciao, Dscho

Ramsay Jones· Jan 15, 2016, 14:53 UTC · re: Johannes Schindelin · lore

Re: [PATCH] t0060: loosen overly strict expectations

On 15/01/16 06:34, Johannes Schindelin wrote:
Show 26 quoted lines
> Hi Ramsay,
> 
> On Fri, 15 Jan 2016, Ramsay Jones wrote:
> 
>> On 14/01/16 22:14, Johannes Sixt wrote:
>>> Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
>>>> Correct me if I'm wrong (quite possible), but _each_ drive has a
>>>> current working directory associated with it in win32, so it's a bit
>>>> difficult to use drive designators with a relative path (eg.
>>>> C:usr/lib).
>>>
>>> As far as it matters for Git, such a path is still an absolute path,
>>> because it is not anchored at $(pwd).
>>
>> [...] seems to contradict what you say above.
>>
>> What am I missing?
> 
> The missing bit is: while C:usr/lib is *not* anchored on $(pwd), it is
> *still* not an absolute path because it is anchored on the current
> directory of the C: drive (the entire idea that some drive state can
> change the meaning of "C:usr/lib" makes it a non-absolute one).
> 
> Since this concept -- a path that is neither relative to $(pwd) nor
> absolute -- does not exist on Linux, I do not think that Git for Windows
> handles this case well at all.

Yep, I may not have expressed it very well, but this is what I was trying say! ;-)

ATB, Ramsay Jones

Johannes Sixt· Jan 15, 2016, 06:54 UTC · re: Ramsay Jones · lore

Re: [PATCH] t0060: loosen overly strict expectations

Am 15.01.2016 um 01:46 schrieb Ramsay Jones:
Show 18 quoted lines
>
>
> On 14/01/16 22:14, Johannes Sixt wrote:
>> Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
>>> Correct me if I'm wrong (quite possible), but
>>> _each_ drive has a current working directory associated with
>>> it in win32, so it's a bit difficult to use drive designators
>>> with a relative path (eg. C:usr/lib).
>>
>> As far as it matters for Git, such a path is still an absolute path,
>> because it is not anchored at $(pwd).
>
> I have been using cygwin on windows since beta-18 (about 1995), in order
> to avoid most of the horrors of the windows command line, so I'm a little
> rusty. ;-)
>
> You know windows _much_ better than me, so could you please educate me
> on this point. I tried this (on windows 8.1):
Show 9 quoted lines
>      C:\cygwin64\home\ramsay\junk>dir C:sub-1
>      dir C:sub-1
>       Volume in drive C is TI31255200A
>       Volume Serial Number is 0024-4AC0
>
>       Directory of C:\cygwin64\home\ramsay\junk\sub-1
>[...]
>
> ... which seems to contradict what you say above.

This example is not super-illuminating. You must cd to a directory on a different drive, say D:\foo, then call dir C:sub-1. The result will be the directory listing from somewhere deep inside the C: hierarchy, not from inside D:\foo.

>
> What am I missing?

Git assumes, given a path in $path that is declared to be relative, that "$path" and "$(pwd)/$path" denote the same thing.

But that does not work when path="C:sub-1". Yeah, "C:sub-1" is relative to something, but *in general* that something is not $(pwd).

-- Hannes
Ramsay Jones· Jan 15, 2016, 14:55 UTC · re: Johannes Sixt · lore

Re: [PATCH] t0060: loosen overly strict expectations

On 15/01/16 06:54, Johannes Sixt wrote:
Show 38 quoted lines
> Am 15.01.2016 um 01:46 schrieb Ramsay Jones:
>>
>>
>> On 14/01/16 22:14, Johannes Sixt wrote:
>>> Am 14.01.2016 um 19:13 schrieb Ramsay Jones:
>>>> Correct me if I'm wrong (quite possible), but
>>>> _each_ drive has a current working directory associated with
>>>> it in win32, so it's a bit difficult to use drive designators
>>>> with a relative path (eg. C:usr/lib).
>>>
>>> As far as it matters for Git, such a path is still an absolute path,
>>> because it is not anchored at $(pwd).
>>
>> I have been using cygwin on windows since beta-18 (about 1995), in order
>> to avoid most of the horrors of the windows command line, so I'm a little
>> rusty. ;-)
>>
>> You know windows _much_ better than me, so could you please educate me
>> on this point. I tried this (on windows 8.1):
> 
>>      C:\cygwin64\home\ramsay\junk>dir C:sub-1
>>      dir C:sub-1
>>       Volume in drive C is TI31255200A
>>       Volume Serial Number is 0024-4AC0
>>
>>       Directory of C:\cygwin64\home\ramsay\junk\sub-1
>> [...]
>>
>> ... which seems to contradict what you say above.
> 
> This example is not super-illuminating. You must cd to a directory on a different drive, say D:\foo, then call dir C:sub-1. The result will be the directory listing from somewhere deep inside the C: hierarchy, not from inside D:\foo.
> 
>>
>> What am I missing?
> 
> Git assumes, given a path in $path that is declared to be relative, that "$path" and "$(pwd)/$path" denote the same thing.
> 
> But that does not work when path="C:sub-1". Yeah, "C:sub-1" is relative to something, but *in general* that something is not $(pwd).

I obviously didn't express myself very well, but your answer seems to be in violent agreement with what I wanted to say! ;-)

ATB, Ramsay Jones

Eric Sunshine· Jan 14, 2016, 18:52 UTC · re: Johannes Schindelin · lore

Re: [PATCH] t0060: loosen overly strict expectations

On Thu, Jan 14, 2016 at 1:48 AM, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:

Show 19 quoted lines
> The dirname() tests file were developed and tested on only the five
> platforms available to the developer at the time, namely: Linux (both 32
> and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.
>
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
> (i.e. the POSIX spec) says, in part:
>
>         If the string pointed to by path consists entirely of the '/'
>         character, basename() shall return a pointer to the string "/".
>         If the string pointed to by path is exactly "//", it is
>         implementation-defined whether "/" or "//" is returned.
>
> The thinking behind testing precise, OS-dependent output values was to
> document that different setups produce different values. However, as the
> test failures on MacOSX illustrated eloquently: hardcoding pretty much each
> and every setup's expectations is pretty fragile.
>
> This is not limited to the "//" vs "/" case, of course, other inputs are
> also allowed to produce multiple outpus by the POSIX specs.
s/outpus/outputs/
Show 5 quoted lines
> So let's just test for all allowed values and be done with it. This still
> documents that Git cannot rely on one particular output value in those
> cases, so the intention of the original tests is still met.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Johannes Schindelin· Jan 15, 2016, 06:35 UTC · re: Eric Sunshine · lore

Re: [PATCH] t0060: loosen overly strict expectations

Hi Eric,
On Thu, 14 Jan 2016, Eric Sunshine wrote:
Show 9 quoted lines
> On Thu, Jan 14, 2016 at 1:48 AM, Johannes Schindelin
> <johannes.schindelin@gmx.de> wrote:
>
> > [...]
> >
> > This is not limited to the "//" vs "/" case, of course, other inputs are
> > also allowed to produce multiple outpus by the POSIX specs.
> 
> s/outpus/outputs/
Whoops.
Junio, would you terribly mind adjusting the commit message on your end?

Ciao, Dscho

Junio C Hamano· Jan 15, 2016, 17:26 UTC · re: Johannes Schindelin · lore

Re: [PATCH] t0060: loosen overly strict expectations

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 8 quoted lines
>> > This is not limited to the "//" vs "/" case, of course, other inputs are
>> > also allowed to produce multiple outpus by the POSIX specs.
>> 
>> s/outpus/outputs/
>
> Whoops.
>
> Junio, would you terribly mind adjusting the commit message on your end?

No problem. Is this the only tweak that is necessary before it can go to 'next' and then to 'master'?

Johannes Schindelin· Jan 19, 2016, 09:40 UTC · re: Junio C Hamano · lore

Re: [PATCH] t0060: loosen overly strict expectations

Hi Junio,
On Fri, 15 Jan 2016, Junio C Hamano wrote:
Show 13 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> > This is not limited to the "//" vs "/" case, of course, other inputs are
> >> > also allowed to produce multiple outpus by the POSIX specs.
> >> 
> >> s/outpus/outputs/
> >
> > Whoops.
> >
> > Junio, would you terribly mind adjusting the commit message on your end?
> 
> No problem.  Is this the only tweak that is necessary before it can
> go to 'next' and then to 'master'?
Sorry to respond so late... Yes, this is the only tweak.

Ciao, Dscho

← back to recent threads