aboutsummaryrefslogtreecommitdiff
path: root/contrib
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2009-05-14 13:05:03 -0700
committerJunio C Hamano <gitster@pobox.com>2009-05-16 22:41:46 -0700
commitda4b3e8c28b1dc2b856d2555ac7bb47ab712598c (patch)
tree48b28d29c4c3e6bc3987e845cbf04cc705849ac1 /contrib
parentb867d324ceb7e5c4f14a04c6b55d69498812d24b (diff)
downloadgit-da4b3e8c28b1dc2b856d2555ac7bb47ab712598c.tar.gz
git-da4b3e8c28b1dc2b856d2555ac7bb47ab712598c.tar.xz
dir.c: clean up handling of 'path' parameter in read_directory_recursive()
Right now we pass two different pathnames ('path' and 'base') down to read_directory_recursive(), and the only real reason for that is that we want to allow an empty 'base' parameter, but when we do so, we need the pathname to "opendir()" to be "." rather than the empty string. And rather than handle that confusion in the caller, we can just fix read_directory_recursive() to handle the case of an empty path itself, by just passing opendir() a "." ourselves if the path is empty. This would allow us to then drop one of the pathnames entirely from the calling convention, but rather than do that, we'll start separating them out as a "filesystem pathname" (the one we use for filesystem accesses) and a "git internal base name" (which is the name that we use for git internally). That will eventually allow us to do things like handle different encodings (eg the filesystem pathnames might be Latin1, while git itself would use UTF-8 for filename information). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib')
0 files changed, 0 insertions, 0 deletions