From: Junio C Hamano Date: Sun, 26 Jul 2026 23:29:12 GMT Subject: Re: [PATCH v4 0/2] mv: report missing destination leading directory Message-ID: In-Reply-To: "Lucas Zamboni Orioli via GitGitGadget" 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.