{"thread":{"id":"7614","subject":"[PATCH 7/6] Fix thinko in subproject entry sorting","startedAt":"2007-04-11T21:39:12Z","lastAt":"2007-04-11T21:51:49Z","messageCount":2,"participants":["Linus Torvalds"],"isPatch":true,"patchVersion":1,"patchTotal":6},"messages":[{"id":"39137","messageId":"Pine.LNX.4.64.0704111423420.6730@woody.linux-foundation.org","threadId":"7614","inReplyTo":null,"subject":"[PATCH 7/6] Fix thinko in subproject entry sorting","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-11T21:39:12Z","receivedAt":"2007-04-11T21:39:12Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nThis fixes a total thinko in my original series: subprojects do *not* sort \nlike directories, because the index is sorted purely by full pathname, and \nsince a subproject shows up in the index as a normal NUL-terminated \nstring, it never has the issues with sorting with the '/' at the end.\n\nSo if you have a subproject \"proj\" and a file \"proj.c\", the subproject \nsorts alphabetically before the file in the index (and must thus also sort \nthat way in a tree object, since trees sort as the index).\n\nIn contrast, it you have two files \"proj/file\" and \"proj.c\", the \"proj.c\" \nwill sort alphabetically before \"proj/file\" in the index. The index \nitself, of course, does not actually contain an entry \"proj/\", but in the \n*tree* that gets written out, the tree entry \"proj\" will sort before the \nfile entry \"proj.c\", which is the only real magic sorting rule.\n\nIn other words: the magic sorting rule only affects tree entries, and \n*only* affects tree entries that point to other trees (ie are of the type \nS_IFDIR).\n\nAnyway, that thinko just means that we should remove the special case to \nmake S_ISDIRLNK entries sort like S_ISDIR entries. They don't.  They sort \nlike normal files.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n---\n\nJunio, you could just fix the patch that I sent out and rebase, but you \nseem to have merged it into \"next\" already, and besides, I think it's ok \nto have this separate correction patch just to explain *why* I was wrong \nto add that special case in the first place. Normally, I don't like \nleaving errors in the history - if they teach anybody anything, it is just \nto make more errors - but this may be one of the rare cases where the \nerror was actually instructive.\n\n\t\tLinus\n---\ndiff --git a/read-cache.c b/read-cache.c\nindex fde2427..795fc5d 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -280,9 +280,9 @@ int base_name_compare(const char *name1, int len1, int mode1,\n \t\treturn cmp;\n \tc1 = name1[len];\n \tc2 = name2[len];\n-\tif (!c1 && (S_ISDIR(mode1) || S_ISDIRLNK(mode1)))\n+\tif (!c1 && S_ISDIR(mode1))\n \t\tc1 = '/';\n-\tif (!c2 && (S_ISDIR(mode2) || S_ISDIRLNK(mode2)))\n+\tif (!c2 && S_ISDIR(mode2))\n \t\tc2 = '/';\n \treturn (c1 < c2) ? -1 : (c1 > c2) ? 1 : 0;\n }\n"},{"id":"39141","messageId":"Pine.LNX.4.64.0704111451090.6730@woody.linux-foundation.org","threadId":"7614","inReplyTo":"Pine.LNX.4.64.0704111423420.6730@woody.linux-foundation.org","subject":"Re: [PATCH 7/6] Fix thinko in subproject entry sorting","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-04-11T21:51:49Z","receivedAt":"2007-04-11T21:51:49Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 11 Apr 2007, Linus Torvalds wrote:\n> \n> In contrast, it you have two files \"proj/file\" and \"proj.c\", the \"proj.c\" \n> will sort alphabetically before \"proj/file\" in the index. The index \n> itself, of course, does not actually contain an entry \"proj/\", but in the \n> *tree* that gets written out, the tree entry \"proj\" will sort before the \n                                                                ^^^^^^\n> file entry \"proj.c\", which is the only real magic sorting rule.\n\nThat \"before\" should be \"after\", of course, otherwise the whole \nexplanation makes no sense..\n\n\t\tLinus\n"}]}