Fix some "git ls-files -o" fallout from gitlinks
authorLinus Torvalds <torvalds@linux-foundation.org>
Sat, 14 Apr 2007 23:22:08 +0000 (16:22 -0700)
committerJunio C Hamano <junkio@cox.net>
Sun, 15 Apr 2007 00:42:58 +0000 (17:42 -0700)
commit5698454ea052369dc98d38b45c21307b07a6c4a3
treeb5264130f1f5c1f228f2a1edf0e290a8e5003853
parentf9135dbcdda7319d12dfc7b5e0b86138719cd3ad
Fix some "git ls-files -o" fallout from gitlinks

Since "git ls-files" doesn't really pass down any details on what it
really wants done to the directory walking code, the directory walking
code doesn't really know whether the caller wants to know about gitlink
directories, or whether it wants to just know about ignored files.

So the directory walking code will return those gitlink directories unless
the caller has explicitly told it not to ("dir->show_other_directories"
tells the directory walker to only show "other" directories).

This kind of confuses "git ls-files -o", because
 - it didn't really expect to see entries listed that were already in the
   index, unless they  were unmerged, and would die on that unexpected
   setup, rather than just "continue".
 - it didn't know how to match directory entries with the final "/"

This trivial change updates the "show_other_files()" function to handle
both of these issues gracefully. There really was no reason to die, when
the obviously correct thing for the function was to just ignore files it
already knew about (that's what "other" means here!).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
builtin-ls-files.c