From: Junio C Hamano <gitster@pobox.com>
To: Lucas Zamboni Orioli <lucaszam0@gmail.com>
Cc: Lucas Zamboni Orioli via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Ben Knoble <ben.knoble@gmail.com>
Subject: Re: [PATCH v2 2/2] mv: check for missing destination directory before renaming
Date: Thu, 23 Jul 2026 16:28:20 -0700 [thread overview]
Message-ID: <xmqqcxwdcmln.fsf@gitster.g> (raw)
In-Reply-To: <CAH01Q-_2APONq2fXmjF=Wo08rTzScMEjyXL-G=_GH6TbjJmTBw@mail.gmail.com> (Lucas Zamboni Orioli's message of "Thu, 23 Jul 2026 18:38:18 -0300")
Lucas Zamboni Orioli <lucaszam0@gmail.com> writes:
>> lstat() can succeed and 'dir_st' may indicate something other than a
>> directory (for example, a symbolic link or a regular file).
>> Alternatively, it can fail with ENOTDIR when, for example, 'dst_dir'
>> is 'a/b/c' and 'a/b' is a file rather than a directory.
>>
>> Both cases will cause 'git mv' into a path assumed to be a directory
>> to fail. Shouldn't we handle these conditions as well?
>
> Yes, agreed, both should be handled. For v3 I switched from lstat()
> to stat() so that the check follows symlinks the same way rename()
> does, and I handle the non-directory cases:
Generally, a symbolic link in a Git-managed working tree should not
be followed. Following a symbolic link would mean that 'git mv x y'
could move 'x' outside the working tree if 'y' is a tracked symbolic
link pointing to a directory outside the working tree. 'git apply',
for example, avoids being fooled by a symbolic link for the same
reason.
I doubt that using stat() instead of lstat() is the right approach.
Doing so essentially amounts to ignoring the presence of symbolic
links.
next prev parent reply other threads:[~2026-07-23 23:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 14:32 [PATCH] mv: report missing destination leading directory Lucas Zamboni Orioli via GitGitGadget
2026-07-15 16:46 ` Ben Knoble
2026-07-22 21:32 ` Lucas Zamboni Orioli
2026-07-23 13:13 ` [PATCH v2 0/2] " Lucas Zamboni Orioli via GitGitGadget
2026-07-23 13:13 ` [PATCH v2 1/2] mv: name both source and destination when rename fails Lucas Zamboni Orioli via GitGitGadget
2026-07-23 17:36 ` Junio C Hamano
2026-07-23 13:13 ` [PATCH v2 2/2] mv: check for missing destination directory before renaming Lucas Zamboni Orioli via GitGitGadget
2026-07-23 17:42 ` Junio C Hamano
2026-07-23 18:30 ` Junio C Hamano
2026-07-23 21:38 ` Lucas Zamboni Orioli
2026-07-23 22:40 ` Junio C Hamano
2026-07-23 23:28 ` Junio C Hamano [this message]
2026-07-23 21:40 ` [PATCH v3 0/2] mv: report missing destination leading directory Lucas Zamboni Orioli via GitGitGadget
2026-07-23 21:40 ` [PATCH v3 1/2] mv: name both source and destination when rename fails Lucas Zamboni Orioli via GitGitGadget
2026-07-23 21:40 ` [PATCH v3 2/2] mv: check for missing destination directory before renaming Lucas Zamboni Orioli via GitGitGadget
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqcxwdcmln.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=lucaszam0@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.