Re: [PATCH] clone: support 'clone --shared' from a worktree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:

> 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 <marcandre.lureau@xxxxxxxxx>
> Signed-off-by: Eric Sunshine <sunshine@xxxxxxxxxxxxxx>
> ---
>  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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux