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