All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] t0060: loosen overly strict expectations
@ 2016-01-14  6:48 Johannes Schindelin
  2016-01-14 17:33 ` Junio C Hamano
  2016-01-14 18:52 ` Eric Sunshine
  0 siblings, 2 replies; 13+ messages in thread
From: Johannes Schindelin @ 2016-01-14  6:48 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: git, Michael Blume, Ramsay Jones, Torsten Bögershausen

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

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

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-14  6:48 [PATCH] t0060: loosen overly strict expectations Johannes Schindelin
@ 2016-01-14 17:33 ` Junio C Hamano
  2016-01-14 18:13   ` Ramsay Jones
  2016-01-14 18:52 ` Eric Sunshine
  1 sibling, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2016-01-14 17:33 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: git, Michael Blume, Ramsay Jones, Torsten Bögershausen

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

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

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-14 17:33 ` Junio C Hamano
@ 2016-01-14 18:13   ` Ramsay Jones
  2016-01-14 22:14     ` Johannes Sixt
  0 siblings, 1 reply; 13+ messages in thread
From: Ramsay Jones @ 2016-01-14 18:13 UTC (permalink / raw)
  To: Junio C Hamano, Johannes Schindelin
  Cc: git, Michael Blume, Torsten Bögershausen



On 14/01/16 17:33, Junio C Hamano wrote:
> 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-14  6:48 [PATCH] t0060: loosen overly strict expectations Johannes Schindelin
  2016-01-14 17:33 ` Junio C Hamano
@ 2016-01-14 18:52 ` Eric Sunshine
  2016-01-15  6:35   ` Johannes Schindelin
  1 sibling, 1 reply; 13+ messages in thread
From: Eric Sunshine @ 2016-01-14 18:52 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Junio C Hamano, Git List, Michael Blume, Ramsay Jones,
	Torsten Bögershausen

On Thu, Jan 14, 2016 at 1:48 AM, Johannes Schindelin
<johannes.schindelin@gmx.de> wrote:
> 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/

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-14 18:13   ` Ramsay Jones
@ 2016-01-14 22:14     ` Johannes Sixt
  2016-01-15  0:46       ` Ramsay Jones
  0 siblings, 1 reply; 13+ messages in thread
From: Johannes Sixt @ 2016-01-14 22:14 UTC (permalink / raw)
  To: Ramsay Jones
  Cc: Junio C Hamano, Johannes Schindelin, git, Michael Blume,
	Torsten Bögershausen

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-14 22:14     ` Johannes Sixt
@ 2016-01-15  0:46       ` Ramsay Jones
  2016-01-15  6:34         ` Johannes Schindelin
  2016-01-15  6:54         ` Johannes Sixt
  0 siblings, 2 replies; 13+ messages in thread
From: Ramsay Jones @ 2016-01-15  0:46 UTC (permalink / raw)
  To: Johannes Sixt
  Cc: Junio C Hamano, Johannes Schindelin, git, Michael Blume,
	Torsten Bögershausen



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

    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


    

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-15  0:46       ` Ramsay Jones
@ 2016-01-15  6:34         ` Johannes Schindelin
  2016-01-15 14:53           ` Ramsay Jones
  2016-01-15  6:54         ` Johannes Sixt
  1 sibling, 1 reply; 13+ messages in thread
From: Johannes Schindelin @ 2016-01-15  6:34 UTC (permalink / raw)
  To: Ramsay Jones
  Cc: Johannes Sixt, Junio C Hamano, git, Michael Blume,
	Torsten Bögershausen

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.

Ciao,
Dscho

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-14 18:52 ` Eric Sunshine
@ 2016-01-15  6:35   ` Johannes Schindelin
  2016-01-15 17:26     ` Junio C Hamano
  0 siblings, 1 reply; 13+ messages in thread
From: Johannes Schindelin @ 2016-01-15  6:35 UTC (permalink / raw)
  To: Eric Sunshine
  Cc: Junio C Hamano, Git List, Michael Blume, Ramsay Jones,
	Torsten Bögershausen

Hi Eric,

On Thu, 14 Jan 2016, Eric Sunshine wrote:

> 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-15  0:46       ` Ramsay Jones
  2016-01-15  6:34         ` Johannes Schindelin
@ 2016-01-15  6:54         ` Johannes Sixt
  2016-01-15 14:55           ` Ramsay Jones
  1 sibling, 1 reply; 13+ messages in thread
From: Johannes Sixt @ 2016-01-15  6:54 UTC (permalink / raw)
  To: Ramsay Jones
  Cc: Junio C Hamano, Johannes Schindelin, git, Michael Blume,
	Torsten Bögershausen

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

-- Hannes

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-15  6:34         ` Johannes Schindelin
@ 2016-01-15 14:53           ` Ramsay Jones
  0 siblings, 0 replies; 13+ messages in thread
From: Ramsay Jones @ 2016-01-15 14:53 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Johannes Sixt, Junio C Hamano, git, Michael Blume,
	Torsten Bögershausen



On 15/01/16 06:34, Johannes Schindelin wrote:
> 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-15  6:54         ` Johannes Sixt
@ 2016-01-15 14:55           ` Ramsay Jones
  0 siblings, 0 replies; 13+ messages in thread
From: Ramsay Jones @ 2016-01-15 14:55 UTC (permalink / raw)
  To: Johannes Sixt
  Cc: Junio C Hamano, Johannes Schindelin, git, Michael Blume,
	Torsten Bögershausen



On 15/01/16 06:54, Johannes Sixt wrote:
> 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-15  6:35   ` Johannes Schindelin
@ 2016-01-15 17:26     ` Junio C Hamano
  2016-01-19  9:40       ` Johannes Schindelin
  0 siblings, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2016-01-15 17:26 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Eric Sunshine, Git List, Michael Blume, Ramsay Jones,
	Torsten Bögershausen

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] t0060: loosen overly strict expectations
  2016-01-15 17:26     ` Junio C Hamano
@ 2016-01-19  9:40       ` Johannes Schindelin
  0 siblings, 0 replies; 13+ messages in thread
From: Johannes Schindelin @ 2016-01-19  9:40 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Eric Sunshine, Git List, Michael Blume, Ramsay Jones,
	Torsten Bögershausen

Hi Junio,

On Fri, 15 Jan 2016, Junio C Hamano wrote:

> 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

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2016-01-19  9:41 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-14  6:48 [PATCH] t0060: loosen overly strict expectations Johannes Schindelin
2016-01-14 17:33 ` Junio C Hamano
2016-01-14 18:13   ` Ramsay Jones
2016-01-14 22:14     ` Johannes Sixt
2016-01-15  0:46       ` Ramsay Jones
2016-01-15  6:34         ` Johannes Schindelin
2016-01-15 14:53           ` Ramsay Jones
2016-01-15  6:54         ` Johannes Sixt
2016-01-15 14:55           ` Ramsay Jones
2016-01-14 18:52 ` Eric Sunshine
2016-01-15  6:35   ` Johannes Schindelin
2016-01-15 17:26     ` Junio C Hamano
2016-01-19  9:40       ` Johannes Schindelin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.