From: Junio C Hamano Date: Wed, 26 Oct 2011 17:37:19 GMT Subject: Re: [PATCH/WIP 02/11] notes-merge: use opendir/readdir instead of using read_directory() Message-ID: <7vmxcn3b8w.fsf@alter.siamese.dyndns.org> In-Reply-To: Nguyen Thai Ngoc Duy writes: > Current read_directory() treats given path separately from contents > inside the path. If the given path has ".git", it's ok (but it'll stop > at .git if during tree recursion). The new read_directory() does not > make this exception, so when note-merge call > read_directory(".git/NOTES_MERGE_WORKTREE"), read_directory() sees > ".git" and stops immediately, assuming it's a gitlink. When read_directory("where/ever") is called, what kind of paths does it collect? Do the paths the function collects share "where/ever" as their common prefix? I thought it collects the paths relative to whatever top-level directory given to the function, so that "where/ever" could be anything. Why does it even have to look at the given path in the first place and make a decision heavier than "can I opendir() and read from it"? In other words, if you see read_directory("some/thing/.git/more/stuff") and find a substring ".git/" in there, what "magic" gitlink handling does the code have to do? I do not think it matters for _this_ particular case, but I can for example imagine an alternative implementation of a merge that uses temporary working tree somewhere other than the main working tree, and one of the natural "temporary" places such a feature in the future may want to use is inside .git/ somewhere. If you are planning to close the door by breaking the behaviour of read_directory(".git/some_where") for such callers with this series, we need to be aware of it, and that is why I am not satisfied by your explanation.