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?
> 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. Isn't
this an absurd limitation to impose? I'm not saying that it's
particularly useful to have a symlink at / pointing to a directory
deeply nested in your repository, but that limitations must have some
concrete rationale.
Anyway, since we're not introducing any regressions (as
has_symlink_leading_path imposes the same absurd limitation), we don't
have to fix this now. But it's certainly something worth fixing in
the future, I think.
--
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