summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: f35a6d3)
raw | patch | inline | side by side (parent: f35a6d3)
author | Linus Torvalds <torvalds@linux-foundation.org> | |
Wed, 11 Apr 2007 21:39:12 +0000 (14:39 -0700) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Thu, 12 Apr 2007 00:21:12 +0000 (17:21 -0700) |
This fixes a total thinko in my original series: subprojects do *not* sort
like directories, because the index is sorted purely by full pathname, and
since a subproject shows up in the index as a normal NUL-terminated
string, it never has the issues with sorting with the '/' at the end.
So if you have a subproject "proj" and a file "proj.c", the subproject
sorts alphabetically before the file in the index (and must thus also sort
that way in a tree object, since trees sort as the index).
In contrast, it you have two files "proj/file" and "proj.c", the "proj.c"
will sort alphabetically before "proj/file" in the index. The index
itself, of course, does not actually contain an entry "proj/", but in the
*tree* that gets written out, the tree entry "proj" will sort after the
file entry "proj.c", which is the only real magic sorting rule.
In other words: the magic sorting rule only affects tree entries, and
*only* affects tree entries that point to other trees (ie are of the type
S_IFDIR).
Anyway, that thinko just means that we should remove the special case to
make S_ISDIRLNK entries sort like S_ISDIR entries. They don't. They sort
like normal files.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
like directories, because the index is sorted purely by full pathname, and
since a subproject shows up in the index as a normal NUL-terminated
string, it never has the issues with sorting with the '/' at the end.
So if you have a subproject "proj" and a file "proj.c", the subproject
sorts alphabetically before the file in the index (and must thus also sort
that way in a tree object, since trees sort as the index).
In contrast, it you have two files "proj/file" and "proj.c", the "proj.c"
will sort alphabetically before "proj/file" in the index. The index
itself, of course, does not actually contain an entry "proj/", but in the
*tree* that gets written out, the tree entry "proj" will sort after the
file entry "proj.c", which is the only real magic sorting rule.
In other words: the magic sorting rule only affects tree entries, and
*only* affects tree entries that point to other trees (ie are of the type
S_IFDIR).
Anyway, that thinko just means that we should remove the special case to
make S_ISDIRLNK entries sort like S_ISDIR entries. They don't. They sort
like normal files.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
read-cache.c | patch | blob | history |
diff --git a/read-cache.c b/read-cache.c
index f458f50458299a3f306812f29a33d2b53dcfdcb2..b8b6d11dba3c08b6746fe7e141d9ad53fa3dee4b 100644 (file)
--- a/read-cache.c
+++ b/read-cache.c
return cmp;
c1 = name1[len];
c2 = name2[len];
- if (!c1 && (S_ISDIR(mode1) || S_ISDIRLNK(mode1)))
+ if (!c1 && S_ISDIR(mode1))
c1 = '/';
- if (!c2 && (S_ISDIR(mode2) || S_ISDIRLNK(mode2)))
+ if (!c2 && S_ISDIR(mode2))
c2 = '/';
return (c1 < c2) ? -1 : (c1 > c2) ? 1 : 0;
}