Re: [PATCH] clone: support 'clone --shared' from a worktree
From: Junio C Hamano <hidden>
Date: 2017-12-12 00:01:53
Eric Sunshine [off-list ref] writes:
quoted hunk
When worktree functionality was originally implemented, the possibility of 'clone --local' from within a worktree was overlooked, with the result that the location of the "objects" directory of the source repository was computed incorrectly, thus the objects could not be copied or hard-linked by the clone. This shortcoming was addressed by 744e469755 (clone: allow --local from a linked checkout, 2015-09-28). However, the related case of 'clone --shared' (despite being handled only a few lines away from the 'clone --local' case) was not fixed by 744e469755, with a similar result of the "objects" directory location being incorrectly computed for insertion into the 'alternates' file. Fix this. Reported-by: Marc-André Lureau <redacted> Signed-off-by: Eric Sunshine <redacted> --- builtin/clone.c | 3 ++- t/t2025-worktree-add.sh | 6 ++++++ 2 files changed, 8 insertions(+), 1 deletion(-)diff --git a/builtin/clone.c b/builtin/clone.c index b22845738a..6ad0ab3fa4 100644 --- a/builtin/clone.c +++ b/builtin/clone.c@@ -452,7 +452,8 @@ static void clone_local(const char *src_repo, const char *dest_repo) { if (option_shared) { struct strbuf alt = STRBUF_INIT; - strbuf_addf(&alt, "%s/objects", src_repo); + get_common_dir(&alt, src_repo); + strbuf_addstr(&alt, "/objects"); add_to_alternates_file(alt.buf); strbuf_release(&alt); } else {
Makes sense. Will queue. Thanks.