Re: [PATCH/WIP 02/11] notes-merge: use opendir/readdir instead of using read_directory()
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 26, 2011, 17:37 UTC
- Message-ID
- <7vmxcn3b8w.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CACsJy8CocoAiVx_PeaaX1oRZvmzfj9-z9JLJkE5unSRVtpGkNA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
Show 6 quoted lines
> 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.