Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html