summaryrefslogtreecommitdiff
path: root/builtin/commit-graph.c
diff options
context:
space:
mode:
authorGlen Choo <chooglen@google.com>2023-04-10 22:18:50 +0000
committerJunio C Hamano <gitster@pobox.com>2023-04-11 08:46:09 -0700
commit4e33535ea98ac16d2163e8e9fcbba5e015881e65 (patch)
tree73ea3c27e42422c1ee5282951e7f78689395aa09 /builtin/commit-graph.c
parentf285f68a132109c234d93490671c00218066ace9 (diff)
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>
Diffstat (limited to 'builtin/commit-graph.c')
0 files changed, 0 insertions, 0 deletions