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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 26, 2026, 23:29 UTC
Message-ID: <xmqqcxw9tjnb.fsf@gitster.g>
In-Reply-To: <pull.2356.v4.git.git.1785097071.gitgitgadget@gmail.com>

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

Show 6 quoted lines

> 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.

Show 5 quoted lines

>  * 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.