{"thread":{"id":"41188","subject":"[PATCH] t0060: loosen overly strict expectations","startedAt":"2016-01-14T06:48:27Z","lastAt":"2016-01-19T09:40:43Z","messageCount":13,"participants":["Johannes Schindelin","Junio C Hamano","Ramsay Jones","Eric Sunshine","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"276007","messageId":"eccf149d9557fd9afb591d9411ecb0b3460c9eb0.1452754049.git.johannes.schindelin@gmx.de","threadId":"41188","inReplyTo":null,"subject":"[PATCH] t0060: loosen overly strict expectations","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-01-14T06:48:27Z","receivedAt":"2016-01-14T06:48:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"The dirname() tests file were developed and tested on only the five\nplatforms available to the developer at the time, namely: Linux (both 32\nand 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.\n\nhttp://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html\n(i.e. the POSIX spec) says, in part:\n\n\tIf the string pointed to by path consists entirely of the '/'\n\tcharacter, basename() shall return a pointer to the string \"/\".\n\tIf the string pointed to by path is exactly \"//\", it is\n\timplementation-defined whether \"/\" or \"//\" is returned.\n\nThe thinking behind testing precise, OS-dependent output values was to\ndocument that different setups produce different values. However, as the\ntest failures on MacOSX illustrated eloquently: hardcoding pretty much each\nand every setup's expectations is pretty fragile.\n\nThis is not limited to the \"//\" vs \"/\" case, of course, other inputs are\nalso allowed to produce multiple outpus by the POSIX specs.\n\nSo let's just test for all allowed values and be done with it. This still\ndocuments that Git cannot rely on one particular output value in those\ncases, so the intention of the original tests is still met.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tThis is the promised fix.\n\n test-path-utils.c | 78 +++++++++++++++----------------------------------------\n 1 file changed, 21 insertions(+), 57 deletions(-)\n\ndiff --git a/test-path-utils.c b/test-path-utils.c\nindex 4ab68ac..c3adcd8 100644\n--- a/test-path-utils.c\n+++ b/test-path-utils.c\n@@ -42,6 +42,7 @@ static void normalize_argv_string(const char **var, const char *input)\n struct test_data {\n \tconst char *from; /* input: transform from this ... */\n \tconst char *to; /* output: ... to this. */\n+\tconst char *alternative; /* output: ... or this. */\n };\n \n static int test_function(struct test_data *data, char *(*func)(char *input),\n@@ -58,11 +59,18 @@ static int test_function(struct test_data *data, char *(*func)(char *input),\n \t\t\tstrcpy(buffer, data[i].from);\n \t\t\tto = func(buffer);\n \t\t}\n-\t\tif (strcmp(to, data[i].to)) {\n+\t\tif (!strcmp(to, data[i].to))\n+\t\t\tcontinue;\n+\t\tif (!data[i].alternative)\n \t\t\terror(\"FAIL: %s(%s) => '%s' != '%s'\\n\",\n \t\t\t\tfuncname, data[i].from, to, data[i].to);\n-\t\t\tfailed = 1;\n-\t\t}\n+\t\telse if (!strcmp(to, data[i].alternative))\n+\t\t\tcontinue;\n+\t\telse\n+\t\t\terror(\"FAIL: %s(%s) => '%s' != '%s', '%s'\\n\",\n+\t\t\t\tfuncname, data[i].from, to, data[i].to,\n+\t\t\t\tdata[i].alternative);\n+\t\tfailed = 1;\n \t}\n \treturn failed;\n }\n@@ -74,15 +82,9 @@ static struct test_data basename_data[] = {\n \t{ \".\", \".\" },\n \t{ \"..\", \"..\" },\n \t{ \"/\", \"/\" },\n-#if defined(__CYGWIN__) && !defined(NO_LIBGEN_H)\n-\t{ \"//\", \"//\" },\n-\t{ \"///\", \"//\" },\n-\t{ \"////\", \"//\" },\n-#else\n-\t{ \"//\", \"/\" },\n-\t{ \"///\", \"/\" },\n-\t{ \"////\", \"/\" },\n-#endif\n+\t{ \"//\", \"/\", \"//\" },\n+\t{ \"///\", \"/\", \"//\" },\n+\t{ \"////\", \"/\", \"//\" },\n \t{ \"usr\", \"usr\" },\n \t{ \"/usr\", \"usr\" },\n \t{ \"/usr/\", \"usr\" },\n@@ -92,7 +94,6 @@ static struct test_data basename_data[] = {\n \t{ \"usr/lib///\", \"lib\" },\n \n #if defined(__MINGW32__) || defined(_MSC_VER)\n-\n \t/* --- win32 type paths --- */\n \t{ \"\\\\usr\", \"usr\" },\n \t{ \"\\\\usr\\\\\", \"usr\" },\n@@ -111,26 +112,9 @@ static struct test_data basename_data[] = {\n \t{ \"C:a\", \"a\" },\n \t{ \"C:/\", \"/\" },\n \t{ \"C:///\", \"/\" },\n-#if defined(NO_LIBGEN_H)\n-\t{ \"\\\\\", \"\\\\\" },\n-\t{ \"\\\\\\\\\", \"\\\\\" },\n-\t{ \"\\\\\\\\\\\\\", \"\\\\\" },\n-#else\n-\n-\t/* win32 platform variations: */\n-#if defined(__MINGW32__)\n-\t{ \"\\\\\", \"/\" },\n-\t{ \"\\\\\\\\\", \"/\" },\n-\t{ \"\\\\\\\\\\\\\", \"/\" },\n-#endif\n-\n-#if defined(_MSC_VER)\n-\t{ \"\\\\\", \"\\\\\" },\n-\t{ \"\\\\\\\\\", \"\\\\\" },\n-\t{ \"\\\\\\\\\\\\\", \"\\\\\" },\n-#endif\n-\n-#endif\n+\t{ \"\\\\\", \"\\\\\", \"/\" },\n+\t{ \"\\\\\\\\\", \"\\\\\", \"/\" },\n+\t{ \"\\\\\\\\\\\\\", \"\\\\\", \"/\" },\n #endif\n \t{ NULL, NULL }\n };\n@@ -142,14 +126,9 @@ static struct test_data dirname_data[] = {\n \t{ \".\", \".\" },\n \t{ \"..\", \".\" },\n \t{ \"/\", \"/\" },\n-\t{ \"//\", \"//\" },\n-#if defined(__CYGWIN__) && !defined(NO_LIBGEN_H)\n-\t{ \"///\", \"//\" },\n-\t{ \"////\", \"//\" },\n-#else\n-\t{ \"///\", \"/\" },\n-\t{ \"////\", \"/\" },\n-#endif\n+\t{ \"//\", \"/\", \"//\" },\n+\t{ \"///\", \"/\", \"//\" },\n+\t{ \"////\", \"/\", \"//\" },\n \t{ \"usr\", \".\" },\n \t{ \"/usr\", \"/\" },\n \t{ \"/usr/\", \"/\" },\n@@ -159,7 +138,6 @@ static struct test_data dirname_data[] = {\n \t{ \"usr/lib///\", \"usr\" },\n \n #if defined(__MINGW32__) || defined(_MSC_VER)\n-\n \t/* --- win32 type paths --- */\n \t{ \"\\\\\", \"\\\\\" },\n \t{ \"\\\\\\\\\", \"\\\\\\\\\" },\n@@ -180,21 +158,7 @@ static struct test_data dirname_data[] = {\n \t{ \"C:usr/lib///\", \"C:usr\" },\n \t{ \"\\\\\\\\\\\\\", \"\\\\\" },\n \t{ \"\\\\\\\\\\\\\\\\\", \"\\\\\" },\n-#if defined(NO_LIBGEN_H)\n-\t{ \"C:\", \"C:.\" },\n-#else\n-\n-\t/* win32 platform variations: */\n-#if defined(__MINGW32__)\n-\t/* the following is clearly wrong ... */\n-\t{ \"C:\", \".\" },\n-#endif\n-\n-#if defined(_MSC_VER)\n-\t{ \"C:\", \"C:.\" },\n-#endif\n-\n-#endif\n+\t{ \"C:\", \"C:.\", \".\" },\n #endif\n \t{ NULL, NULL }\n };\n-- \n2.6.3.windows.1.300.g1c25e49\n"},{"id":"276060","messageId":"xmqqziw8jcbr.fsf@gitster.mtv.corp.google.com","threadId":"41188","inReplyTo":"eccf149d9557fd9afb591d9411ecb0b3460c9eb0.1452754049.git.johannes.schindelin@gmx.de","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-14T17:33:12Z","receivedAt":"2016-01-14T17:33:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> The dirname() tests file were developed and tested on only the five\n> platforms available to the developer at the time, namely: Linux (both 32\n> and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.\n>\n> http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html\n> (i.e. the POSIX spec) says, in part:\n>\n> \tIf the string pointed to by path consists entirely of the '/'\n> \tcharacter, basename() shall return a pointer to the string \"/\".\n> \tIf the string pointed to by path is exactly \"//\", it is\n> \timplementation-defined whether \"/\" or \"//\" is returned.\n>\n> The thinking behind testing precise, OS-dependent output values was to\n> document that different setups produce different values. However, as the\n> test failures on MacOSX illustrated eloquently: hardcoding pretty much each\n> and every setup's expectations is pretty fragile.\n>\n> This is not limited to the \"//\" vs \"/\" case, of course, other inputs are\n> also allowed to produce multiple outpus by the POSIX specs.\n>\n> So let's just test for all allowed values and be done with it. This still\n> documents that Git cannot rely on one particular output value in those\n> cases, so the intention of the original tests is still met.\n>\n> Signed-off-by: Johannes Schindelin \n> ---\n\nSounds sensible. Thanks.\n\nThis is not a problem with this patch, but the resulting\nbasename_data[] array seems to test \"C:/usr\" going to \"usr\" twice\nunder _MSC_VER or __MINGW32__.\n\nAlso...\n\n> -#if defined(__MINGW32__)\n> -\t/* the following is clearly wrong ... */\n> -\t{ \"C:\", \".\" },\n> -#endif\n> -\n> -#if defined(_MSC_VER)\n> -\t{ \"C:\", \"C:.\" },\n> -#endif\n> -\n> -#endif\n> +\t{ \"C:\", \"C:.\", \".\" },\n> #endif\n\n\"C:\" is still allowed to go to \".\"; is it still \"clearly wrong\",\nor do we have a reason why we think it is not wrong at all?\n\nI think the comment was written by Ramsay and also suspect that you\ndid not specifically agree or disagree with that particular\ndecision, so I'd understand if you do not have a strong opinion\neither way, but I'd like to hear from Ramsay. Perhaps earlier we\nthought it was clearly wrong but we no longer do?\n"},{"id":"276061","messageId":"5697E550.9020102@ramsayjones.plus.com","threadId":"41188","inReplyTo":"xmqqziw8jcbr.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-01-14T18:13:36Z","receivedAt":"2016-01-14T18:13:36Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 14/01/16 17:33, Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n> Also...\n> \n>> -#if defined(__MINGW32__)\n>> -\t/* the following is clearly wrong ... */\n>> -\t{ \"C:\", \".\" },\n>> -#endif\n>> -\n>> -#if defined(_MSC_VER)\n>> -\t{ \"C:\", \"C:.\" },\n>> -#endif\n>> -\n>> -#endif\n>> +\t{ \"C:\", \"C:.\", \".\" },\n>> #endif\n> \n> \"C:\" is still allowed to go to \".\"; is it still \"clearly wrong\",\n> or do we have a reason why we think it is not wrong at all?\n> \n> I think the comment was written by Ramsay and also suspect that you\n> did not specifically agree or disagree with that particular\n> decision, so I'd understand if you do not have a strong opinion\n> either way, but I'd like to hear from Ramsay. Perhaps earlier we\n> thought it was clearly wrong but we no longer do?\n> \n\nYes, that comment was mine. The result is \"clearly wrong\" if you\nfollow the POSIX rules [1], but that may not translate exactly to\na dos like path. ;-)\n\nI think the question is: does it make a difference if you call\nchdir() on the result? Which brings up something which I have\nbeen ignoring. Correct me if I'm wrong (quite possible), but\n_each_ drive has a current working directory associated with\nit in win32, so it's a bit difficult to use drive designators\nwith a relative path (eg. C:usr/lib).\n\nNote: The test data in the test-libgen.c file was using Linux\nas the 'benchmark' for the POSIX paths and IIRC MinGW-32 for\nthe dos paths. (Note that I said 'benchmark' _not_ 'correct'). :-P\n\nATB,\nRamsay Jones\n\n[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/dirname.html\n"},{"id":"276068","messageId":"CAPig+cRa9mk0U4iPim5GRWzFN-vHEA=rx8bb40oQyCJVZL7t3A@mail.gmail.com","threadId":"41188","inReplyTo":"eccf149d9557fd9afb591d9411ecb0b3460c9eb0.1452754049.git.johannes.schindelin@gmx.de","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2016-01-14T18:52:11Z","receivedAt":"2016-01-14T18:52:11Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Thu, Jan 14, 2016 at 1:48 AM, Johannes Schindelin\n wrote:\n> The dirname() tests file were developed and tested on only the five\n> platforms available to the developer at the time, namely: Linux (both 32\n> and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.\n>\n> http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html\n> (i.e. the POSIX spec) says, in part:\n>\n> If the string pointed to by path consists entirely of the '/'\n> character, basename() shall return a pointer to the string \"/\".\n> If the string pointed to by path is exactly \"//\", it is\n> implementation-defined whether \"/\" or \"//\" is returned.\n>\n> The thinking behind testing precise, OS-dependent output values was to\n> document that different setups produce different values. However, as the\n> test failures on MacOSX illustrated eloquently: hardcoding pretty much each\n> and every setup's expectations is pretty fragile.\n>\n> This is not limited to the \"//\" vs \"/\" case, of course, other inputs are\n> also allowed to produce multiple outpus by the POSIX specs.\n\ns/outpus/outputs/\n\n> So let's just test for all allowed values and be done with it. This still\n> documents that Git cannot rely on one particular output value in those\n> cases, so the intention of the original tests is still met.\n>\n> Signed-off-by: Johannes Schindelin \n"},{"id":"276087","messageId":"56981DC2.6070706@kdbg.org","threadId":"41188","inReplyTo":"5697E550.9020102@ramsayjones.plus.com","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-01-14T22:14:26Z","receivedAt":"2016-01-14T22:14:26Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 14.01.2016 um 19:13 schrieb Ramsay Jones:\n> Correct me if I'm wrong (quite possible), but\n> _each_ drive has a current working directory associated with\n> it in win32, so it's a bit difficult to use drive designators\n> with a relative path (eg. C:usr/lib).\n\nAs far as it matters for Git, such a path is still an absolute path, \nbecause it is not anchored at $(pwd).\n\n-- Hannes\n"},{"id":"276114","messageId":"5698415E.7070907@ramsayjones.plus.com","threadId":"41188","inReplyTo":"56981DC2.6070706@kdbg.org","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-01-15T00:46:22Z","receivedAt":"2016-01-15T00:46:22Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 14/01/16 22:14, Johannes Sixt wrote:\n> Am 14.01.2016 um 19:13 schrieb Ramsay Jones:\n>> Correct me if I'm wrong (quite possible), but\n>> _each_ drive has a current working directory associated with\n>> it in win32, so it's a bit difficult to use drive designators\n>> with a relative path (eg. C:usr/lib).\n> \n> As far as it matters for Git, such a path is still an absolute path, \n> because it is not anchored at $(pwd).\n\nI have been using cygwin on windows since beta-18 (about 1995), in order\nto avoid most of the horrors of the windows command line, so I'm a little\nrusty. ;-)\n\nYou know windows _much_ better than me, so could you please educate me\non this point. I tried this (on windows 8.1):\n\n ramsay@satellite $ cmd\n Microsoft Windows [Version 6.3.9600]\n (c) 2013 Microsoft Corporation. All rights reserved.\n \n C:\\cygwin64\\home\\ramsay>cd junk\n cd junk\n \n C:\\cygwin64\\home\\ramsay\\junk>dir\n dir\n Volume in drive C is TI31255200A\n Volume Serial Number is 0024-4AC0\n \n Directory of C:\\cygwin64\\home\\ramsay\\junk\n \n 15/01/2016 00:23 .\n 15/01/2016 00:23 ..\n 15/01/2016 00:23 1 regular\n 15/01/2016 00:23 sub-1\n 15/01/2016 00:24 sub-2\n 1 File(s) 1 bytes\n 4 Dir(s) 800,988,291,072 bytes free\n \n C:\\cygwin64\\home\\ramsay\\junk>dir C:\n dir C:\n Volume in drive C is TI31255200A\n Volume Serial Number is 0024-4AC0\n \n Directory of C:\\cygwin64\\home\\ramsay\\junk\n \n 15/01/2016 00:23 .\n 15/01/2016 00:23 ..\n 15/01/2016 00:23 1 regular\n 15/01/2016 00:23 sub-1\n 15/01/2016 00:24 sub-2\n 1 File(s) 1 bytes\n 4 Dir(s) 800,988,291,072 bytes free\n \n C:\\cygwin64\\home\\ramsay\\junk>dir C:.\n dir C:.\n Volume in drive C is TI31255200A\n Volume Serial Number is 0024-4AC0\n \n Directory of C:\\cygwin64\\home\\ramsay\\junk\n \n 15/01/2016 00:23 .\n 15/01/2016 00:23 ..\n 15/01/2016 00:23 1 regular\n 15/01/2016 00:23 sub-1\n 15/01/2016 00:24 sub-2\n 1 File(s) 1 bytes\n 4 Dir(s) 800,988,291,072 bytes free\n \n C:\\cygwin64\\home\\ramsay\\junk>dir C:\\\n dir C:\\\n Volume in drive C is TI31255200A\n Volume Serial Number is 0024-4AC0\n \n Directory of C:\\\n \n 17/09/2015 15:52 cygwin64\n 05/08/2015 10:10 383 ftconfig.ini\n 09/04/2014 05:41 Intel\n 22/08/2013 15:22 PerfLogs\n 06/10/2015 19:28 Program Files\n 26/12/2015 14:09 Program Files (x86)\n 18/05/2014 11:18 0 Recovery.txt\n 03/12/2013 17:02 Toshiba\n 25/06/2014 18:15 UBIOS\n 26/12/2015 14:09 Users\n 27/08/2015 10:08 Windows\n 2 File(s) 383 bytes\n 9 Dir(s) 800,988,299,264 bytes free\n \n C:\\cygwin64\\home\\ramsay\\junk>dir C:sub-1\n dir C:sub-1\n Volume in drive C is TI31255200A\n Volume Serial Number is 0024-4AC0\n \n Directory of C:\\cygwin64\\home\\ramsay\\junk\\sub-1\n \n 15/01/2016 00:23 .\n 15/01/2016 00:23 ..\n 15/01/2016 00:23 1 bill\n 15/01/2016 00:23 1 fred\n 2 File(s) 2 bytes\n 2 Dir(s) 800,988,299,264 bytes free\n \n C:\\cygwin64\\home\\ramsay\\junk>exit\n exit\n ramsay@satellite $ \n\n... which seems to contradict what you say above.\n\nWhat am I missing?\n\nATB,\nRamsay Jones\n\n\n \n"},{"id":"276123","messageId":"alpine.DEB.2.20.1601150730440.2964@virtualbox","threadId":"41188","inReplyTo":"5698415E.7070907@ramsayjones.plus.com","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-01-15T06:34:21Z","receivedAt":"2016-01-15T06:34:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ramsay,\n\nOn Fri, 15 Jan 2016, Ramsay Jones wrote:\n\n> On 14/01/16 22:14, Johannes Sixt wrote:\n> > Am 14.01.2016 um 19:13 schrieb Ramsay Jones:\n> >> Correct me if I'm wrong (quite possible), but _each_ drive has a\n> >> current working directory associated with it in win32, so it's a bit\n> >> difficult to use drive designators with a relative path (eg.\n> >> C:usr/lib).\n> > \n> > As far as it matters for Git, such a path is still an absolute path,\n> > because it is not anchored at $(pwd).\n> \n> [...] seems to contradict what you say above.\n> \n> What am I missing?\n\nThe missing bit is: while C:usr/lib is *not* anchored on $(pwd), it is\n*still* not an absolute path because it is anchored on the current\ndirectory of the C: drive (the entire idea that some drive state can\nchange the meaning of \"C:usr/lib\" makes it a non-absolute one).\n\nSince this concept -- a path that is neither relative to $(pwd) nor\nabsolute -- does not exist on Linux, I do not think that Git for Windows\nhandles this case well at all.\n\nCiao,\nDscho\n"},{"id":"276124","messageId":"alpine.DEB.2.20.1601150734460.2964@virtualbox","threadId":"41188","inReplyTo":"CAPig+cRa9mk0U4iPim5GRWzFN-vHEA=rx8bb40oQyCJVZL7t3A@mail.gmail.com","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-01-15T06:35:34Z","receivedAt":"2016-01-15T06:35:34Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Eric,\n\nOn Thu, 14 Jan 2016, Eric Sunshine wrote:\n\n> On Thu, Jan 14, 2016 at 1:48 AM, Johannes Schindelin\n> wrote:\n>\n> > [...]\n> >\n> > This is not limited to the \"//\" vs \"/\" case, of course, other inputs are\n> > also allowed to produce multiple outpus by the POSIX specs.\n> \n> s/outpus/outputs/\n\nWhoops.\n\nJunio, would you terribly mind adjusting the commit message on your end?\n\nCiao,\nDscho\n"},{"id":"276127","messageId":"569897B7.4040302@kdbg.org","threadId":"41188","inReplyTo":"5698415E.7070907@ramsayjones.plus.com","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2016-01-15T06:54:47Z","receivedAt":"2016-01-15T06:54:47Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 15.01.2016 um 01:46 schrieb Ramsay Jones:\n>\n>\n> On 14/01/16 22:14, Johannes Sixt wrote:\n>> Am 14.01.2016 um 19:13 schrieb Ramsay Jones:\n>>> Correct me if I'm wrong (quite possible), but\n>>> _each_ drive has a current working directory associated with\n>>> it in win32, so it's a bit difficult to use drive designators\n>>> with a relative path (eg. C:usr/lib).\n>>\n>> As far as it matters for Git, such a path is still an absolute path,\n>> because it is not anchored at $(pwd).\n>\n> I have been using cygwin on windows since beta-18 (about 1995), in order\n> to avoid most of the horrors of the windows command line, so I'm a little\n> rusty. ;-)\n>\n> You know windows _much_ better than me, so could you please educate me\n> on this point. I tried this (on windows 8.1):\n\n> C:\\cygwin64\\home\\ramsay\\junk>dir C:sub-1\n> dir C:sub-1\n> Volume in drive C is TI31255200A\n> Volume Serial Number is 0024-4AC0\n>\n> Directory of C:\\cygwin64\\home\\ramsay\\junk\\sub-1\n>[...]\n>\n> ... which seems to contradict what you say above.\n\nThis example is not super-illuminating. You must cd to a directory on a \ndifferent drive, say D:\\foo, then call dir C:sub-1. The result will be \nthe directory listing from somewhere deep inside the C: hierarchy, not \nfrom inside D:\\foo.\n\n>\n> What am I missing?\n\nGit assumes, given a path in $path that is declared to be relative, that \n\"$path\" and \"$(pwd)/$path\" denote the same thing.\n\nBut that does not work when path=\"C:sub-1\". Yeah, \"C:sub-1\" is relative \nto something, but *in general* that something is not $(pwd).\n\n-- Hannes\n"},{"id":"276158","messageId":"569907E2.9070104@ramsayjones.plus.com","threadId":"41188","inReplyTo":"alpine.DEB.2.20.1601150730440.2964@virtualbox","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-01-15T14:53:22Z","receivedAt":"2016-01-15T14:53:22Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 15/01/16 06:34, Johannes Schindelin wrote:\n> Hi Ramsay,\n> \n> On Fri, 15 Jan 2016, Ramsay Jones wrote:\n> \n>> On 14/01/16 22:14, Johannes Sixt wrote:\n>>> Am 14.01.2016 um 19:13 schrieb Ramsay Jones:\n>>>> Correct me if I'm wrong (quite possible), but _each_ drive has a\n>>>> current working directory associated with it in win32, so it's a bit\n>>>> difficult to use drive designators with a relative path (eg.\n>>>> C:usr/lib).\n>>>\n>>> As far as it matters for Git, such a path is still an absolute path,\n>>> because it is not anchored at $(pwd).\n>>\n>> [...] seems to contradict what you say above.\n>>\n>> What am I missing?\n> \n> The missing bit is: while C:usr/lib is *not* anchored on $(pwd), it is\n> *still* not an absolute path because it is anchored on the current\n> directory of the C: drive (the entire idea that some drive state can\n> change the meaning of \"C:usr/lib\" makes it a non-absolute one).\n> \n> Since this concept -- a path that is neither relative to $(pwd) nor\n> absolute -- does not exist on Linux, I do not think that Git for Windows\n> handles this case well at all.\n\nYep, I may not have expressed it very well, but this is what I was trying\nsay! ;-)\n\nATB,\nRamsay Jones\n"},{"id":"276159","messageId":"56990854.5080005@ramsayjones.plus.com","threadId":"41188","inReplyTo":"569897B7.4040302@kdbg.org","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-01-15T14:55:16Z","receivedAt":"2016-01-15T14:55:16Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 15/01/16 06:54, Johannes Sixt wrote:\n> Am 15.01.2016 um 01:46 schrieb Ramsay Jones:\n>>\n>>\n>> On 14/01/16 22:14, Johannes Sixt wrote:\n>>> Am 14.01.2016 um 19:13 schrieb Ramsay Jones:\n>>>> Correct me if I'm wrong (quite possible), but\n>>>> _each_ drive has a current working directory associated with\n>>>> it in win32, so it's a bit difficult to use drive designators\n>>>> with a relative path (eg. C:usr/lib).\n>>>\n>>> As far as it matters for Git, such a path is still an absolute path,\n>>> because it is not anchored at $(pwd).\n>>\n>> I have been using cygwin on windows since beta-18 (about 1995), in order\n>> to avoid most of the horrors of the windows command line, so I'm a little\n>> rusty. ;-)\n>>\n>> You know windows _much_ better than me, so could you please educate me\n>> on this point. I tried this (on windows 8.1):\n> \n>> C:\\cygwin64\\home\\ramsay\\junk>dir C:sub-1\n>> dir C:sub-1\n>> Volume in drive C is TI31255200A\n>> Volume Serial Number is 0024-4AC0\n>>\n>> Directory of C:\\cygwin64\\home\\ramsay\\junk\\sub-1\n>> [...]\n>>\n>> ... which seems to contradict what you say above.\n> \n> 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.\n> \n>>\n>> What am I missing?\n> \n> Git assumes, given a path in $path that is declared to be relative, that \"$path\" and \"$(pwd)/$path\" denote the same thing.\n> \n> 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).\n\nI obviously didn't express myself very well, but your answer seems to\nbe in violent agreement with what I wanted to say! ;-)\n\nATB,\nRamsay Jones\n"},{"id":"276175","messageId":"xmqq60yukb49.fsf@gitster.mtv.corp.google.com","threadId":"41188","inReplyTo":"alpine.DEB.2.20.1601150734460.2964@virtualbox","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-15T17:26:14Z","receivedAt":"2016-01-15T17:26:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> > This is not limited to the \"//\" vs \"/\" case, of course, other inputs are\n>> > also allowed to produce multiple outpus by the POSIX specs.\n>> \n>> s/outpus/outputs/\n>\n> Whoops.\n>\n> Junio, would you terribly mind adjusting the commit message on your end?\n\nNo problem. Is this the only tweak that is necessary before it can\ngo to 'next' and then to 'master'?\n"},{"id":"276339","messageId":"alpine.DEB.2.20.1601191034000.2964@virtualbox","threadId":"41188","inReplyTo":"xmqq60yukb49.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] t0060: loosen overly strict expectations","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2016-01-19T09:40:43Z","receivedAt":"2016-01-19T09:40:43Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Fri, 15 Jan 2016, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> > This is not limited to the \"//\" vs \"/\" case, of course, other inputs are\n> >> > also allowed to produce multiple outpus by the POSIX specs.\n> >> \n> >> s/outpus/outputs/\n> >\n> > Whoops.\n> >\n> > Junio, would you terribly mind adjusting the commit message on your end?\n> \n> No problem. Is this the only tweak that is necessary before it can\n> go to 'next' and then to 'master'?\n\nSorry to respond so late... Yes, this is the only tweak.\n\nCiao,\nDscho\n"}]}