Re: [PATCH v4 0/2] mv: report missing destination leading directory

[Junio C Hamano <gitster@pobox.com>]

"Lucas Zamboni Orioli via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> Changes in v4:
>
>  * reverted to lstat and added has_symlink_leading_path() to refuse a
>    destination that goes through a symbolic link, independent of the link
>    target, per Junio C Hamano's point that Git tracks symlinks and must not
>    follow them here

I'll review the series tomorrow, but the use of the helper function
has_symlink_leading_path() in other contexts like 'git apply' rings
a bell.  I agree the problem you face is exactly the issue the helper
function aims to address.


>  * added new "destination is beyond a symbolic link" message
>  * added tests: symlink as immediate parent and as intermediate component,
>    symlink at the destination, -f does not bypass the symlink refusal, and a
>    regression test that a move through a symlink no longer corrupts the
>    index (see the reproduction reported on the list)

Sounds good.

When 'y' is a symbolic link to some directory (say, 'a/b'), we do
not want 'git mv x y' to create 'y/x' at the same time we have 'y'
as a symbolic link.  It may be OK if the result has 'a/b/x' (a file
in a directory) and 'y' (a symbolic link), but I think that would
be more confusing than it is worth.

Thanks.