On 00:33 Fri 09 Jan , Junio C Hamano wrote: > Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > > > Johannes Sixt schrieb: > >> Alexander Potashev schrieb: > >>> - if ((ent->d_name[0] == '.') && > >>> - (ent->d_name[1] == 0 || > >>> - ((ent->d_name[1] == '.') && (ent->d_name[2] == 0)))) > >>> + if (is_pseudo_dir_name(ent->d_name)) > >> > >> Nit-pick: When I read the resulting code, then I will have to look up that > >> is_pseudo_dir_name() indeed only checks for "." and "..". But if it were > >> named is_dot_or_dotdot(), then I would have to do that. > > > > ... then I would *not* have to do that, of course. > > I think the unstated motivation of this choice of the name is to keep the > door open to include lost+found and friends to the repertoire, and perhaps > to have an isolated place for customization for non-POSIX platforms and > for local conventions. It is more like is_uninteresting_dirent_name(). I didn't think over the support of 'lost+found'. But the name like is_uninteresting_dirent_name is more flexible, indeed. I prefer a bit shorter name, 'is_dummy_dirent_name'. But if you're going to support 'lost+found's, remember that a Git repository might have its own 'lost+found' directory. It's a bit crazy, but it's possible: --- lost+found/file | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 lost+found/file diff --git a/lost+found/file b/lost+found/file new file mode 100644 index 0000000..190a180 --- /dev/null +++ b/lost+found/file @@ -0,0 +1 @@ +123 -- Git shouldn't allow to clone at least repositories that have lost+found directory into a directory with already existing lost+found (neither it's a ordinary directory created using 'mkdir' nor it's an ext2's property) We should probably forbid cloning to a directory with lost+found, because a 'lost+found' may appear after pulling from somebody and the user won't be able to resolve this anyhow. > > As long as this function is used only to detect and skip "uninteresting" > dirent, I think that is not a bad direction. > > On the other hand, I am a bit worried about is_empty_dir() abused outside > its intended purpose to say "this directory does not have anything > interesting". E.g. "Oh, it's empty so we can nuke it": I propose to rename it (if it's really necessary) to is_clean_dir, which means "There's no old crap here, we can safely clone". > > if (is_empty_dir(dir)) > rmdir(dir); > > even though the current callers do not do something crazy like this (the > usual order we do things is rmdir() and then check for errors). I think, it's rather early to send [PATCHES v2] (with updated function names), will wait for your comments. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
