Ramkumar Ramachandra <artag...@gmail.com> writes: > Junio C Hamano wrote: >> I think what the callers of this function care about is if the name >> is a path that should not be added to our index (i.e. points >> "outside the repository"). If you had a symlink d that points at e >> when our project does have a subdirectory e with file f, >> >> check_leading_path("d/f") >> >> wants to say "bad", even though the real file pointed at, i.e. "e/f" >> is inside our working tree, so "outside our working tree" is not >> quite correct in the strict sense (this applies equally to >> has_symlink_leading_path), but > > Actually, you introduced one naming regression: > has_symlink_leading_path() is a good name for what the function does, > as opposed to die_if_path_outside_our_tree(), which is misleading. > What about die_if_path_contains_links() to encapsulate gitlinks and > symlinks?
The cases we know that "$d/f" (where $d is a path that is one or more levels, e.g. "dir", "d/i", or "d/i/r") is bad are when - "$d" is a symlink, because what you could add to the index is "$d" and nothing underneath it; or - "$d" is a directory that is the top level of the working tree that is controled by "$d/.git", because what you could add to the index is "$d" and nothing underneath it. If "$d" were added to our index, the former will make 120000 entry and the latter will make 160000 entry. But the user may not want to add $d ever to our project, so in that case, neither will give us a symlink or a gitlink. We should find a word that makes it clear that "this path is beyond something we _could_ add". I do not think "link" is a good word for it. It shares the same mistake that led to the original misnomer, i.e. "the case we happened to notice was when we have symlink so let's name it with 'symlink' somewhere in it." >> I think we should treat the case >> where "d" (and "d/f") belongs to the working tree of a repository >> for a separate project, that is embedded in our working tree the >> same way. > > I'm not too sure about this. It means that I can have symlinks to > files in various parts of my worktree, but not to directories. It does not mean that. It is valid to do ln -s myetc /etc git add myetc It is NOT valid to do git add myetc/passwd One can have symlinks to anywhere all one wants. We track symlinks. It is the same for the top-level of the working tree of a separate project, be it a submodule or not. It is valid to do mkdir foo && (cd foo && git init && >file) git add foo It is NOT valid to do git add foo/file -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html