]> git.ipfire.org Git - thirdparty/git.git/commit
clone: error specifically with --local and symlinked objects
authorGlen Choo <chooglen@google.com>
Mon, 10 Apr 2023 22:18:50 +0000 (22:18 +0000)
committerJunio C Hamano <gitster@pobox.com>
Tue, 11 Apr 2023 15:46:09 +0000 (08:46 -0700)
commit4e33535ea98ac16d2163e8e9fcbba5e015881e65
tree73ea3c27e42422c1ee5282951e7f78689395aa09
parentf285f68a132109c234d93490671c00218066ace9
clone: error specifically with --local and symlinked objects

6f054f9fb3 (builtin/clone.c: disallow --local clones with
symlinks, 2022-07-28) gives a good error message when "git clone
--local" fails when the repo to clone has symlinks in
"$GIT_DIR/objects". In bffc762f87 (dir-iterator: prevent top-level
symlinks without FOLLOW_SYMLINKS, 2023-01-24), we later extended this
restriction to the case where "$GIT_DIR/objects" is itself a symlink,
but we didn't update the error message then - bffc762f87's tests show
that we print a generic "failed to start iterator over" message.

This is exacerbated by the fact that Documentation/git-clone.txt
mentions neither restriction, so users are left wondering if this is
intentional behavior or not.

Fix this by adding a check to builtin/clone.c: when doing a local clone,
perform an extra check to see if "$GIT_DIR/objects" is a symlink, and if
so, assume that that was the reason for the failure and report the
relevant information. Ideally, dir_iterator_begin() would tell us that
the real failure reason is the presence of the symlink, but (as far as I
can tell) there isn't an appropriate errno value for that.

Also, update Documentation/git-clone.txt to reflect that this
restriction exists.

Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-clone.txt
builtin/clone.c
t/t5604-clone-reference.sh