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

2017-12-11 Thread Brandon Williams
On 12/11, Eric Sunshine wrote:
> On Mon, Dec 11, 2017 at 7:18 PM, Brandon Williams  wrote:
> > On 12/11, Eric Sunshine wrote:
> >>   struct strbuf alt = STRBUF_INIT;
> >> - strbuf_addf(, "%s/objects", src_repo);
> >> + get_common_dir(, src_repo);
> >> + strbuf_addstr(, "/objects");
> >
> > If you wanted to do this in one function call you could either use
> > 'strbuf_git_common_path()' or either 'strbuf_git_path()' or
> > 'strbuf_repo_git_path()' which will do the proper path adjustments when
> > working on a path which should be shared between worktrees (i.e. part of
> > the common git dir).
> 
> Thanks for the pointers, however, the above fix mirrors the fix made
> by 744e469755 (clone: allow --local from a linked checkout,
> 2015-09-28) to code immediately below it in the 'else' arm:
> 
> get_common_dir(, src_repo);
> get_common_dir(, dest_repo);
> strbuf_addstr(, "/objects");
> strbuf_addstr(, "/objects");
> 
> It would be poor form and confusing to use one of the mechanisms you
> suggest while leaving the 'else' arm untouched.
> 
> Re-working both arms of the 'if' to use one of the suggested functions
> would make a fine follow-on or preparatory patch, however, I'd rather
> not hold up this fix merely to re-roll for such a minor cleanup. (I
> also considered a follow-on patch to reduce the duplication between
> the two cases but decided against it, for the present, since such a
> patch would almost be noise without much gain.)

I didn't look close enough at what you were trying to fix, you're right
I think what you have here is good as the alternative would require a
lot more reworking I think (at least to change the above part too).

Either way though, I'm a little worried about what happens if you have
GIT_COMMON_DIR set because then both the src and dest repo would share a
common dir, I don't know if that is expected or not.  Maybe something
else to consider later.

> 
> By the way, is there any documentation explaining the differences
> between all these similar functions and when one should be used over
> the others?

I wish, I probably should have done a better job documenting it all in
path.h when I added the repo_* flavor of functions.  I'll add that to my
list of things to do though :)

-- 
Brandon Williams


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

2017-12-11 Thread Eric Sunshine
On Mon, Dec 11, 2017 at 7:18 PM, Brandon Williams  wrote:
> On 12/11, Eric Sunshine wrote:
>>   struct strbuf alt = STRBUF_INIT;
>> - strbuf_addf(, "%s/objects", src_repo);
>> + get_common_dir(, src_repo);
>> + strbuf_addstr(, "/objects");
>
> If you wanted to do this in one function call you could either use
> 'strbuf_git_common_path()' or either 'strbuf_git_path()' or
> 'strbuf_repo_git_path()' which will do the proper path adjustments when
> working on a path which should be shared between worktrees (i.e. part of
> the common git dir).

Thanks for the pointers, however, the above fix mirrors the fix made
by 744e469755 (clone: allow --local from a linked checkout,
2015-09-28) to code immediately below it in the 'else' arm:

get_common_dir(, src_repo);
get_common_dir(, dest_repo);
strbuf_addstr(, "/objects");
strbuf_addstr(, "/objects");

It would be poor form and confusing to use one of the mechanisms you
suggest while leaving the 'else' arm untouched.

Re-working both arms of the 'if' to use one of the suggested functions
would make a fine follow-on or preparatory patch, however, I'd rather
not hold up this fix merely to re-roll for such a minor cleanup. (I
also considered a follow-on patch to reduce the duplication between
the two cases but decided against it, for the present, since such a
patch would almost be noise without much gain.)

By the way, is there any documentation explaining the differences
between all these similar functions and when one should be used over
the others?


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

2017-12-11 Thread Brandon Williams
On 12/11, Eric Sunshine wrote:
> 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 
> Signed-off-by: Eric Sunshine 
> ---
>  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(, "%s/objects", src_repo);
> + get_common_dir(, src_repo);
> + strbuf_addstr(, "/objects");

If you wanted to do this in one function call you could either use
'strbuf_git_common_path()' or either 'strbuf_git_path()' or
'strbuf_repo_git_path()' which will do the proper path adjustments when
working on a path which should be shared between worktrees (i.e. part of
the common git dir).

>   add_to_alternates_file(alt.buf);
>   strbuf_release();
>   } else {
> diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
> index b5c47ac602..7395973318 100755
> --- a/t/t2025-worktree-add.sh
> +++ b/t/t2025-worktree-add.sh
> @@ -245,6 +245,12 @@ test_expect_success 'local clone from linked checkout' '
>   ( cd here-clone && git fsck )
>  '
>  
> +test_expect_success 'local clone --shared from linked checkout' '
> + git -C bare worktree add --detach ../baretree &&
> + git clone --local --shared baretree bare-clone &&
> + grep /bare/ bare-clone/.git/objects/info/alternates
> +'
> +
>  test_expect_success '"add" worktree with --no-checkout' '
>   git worktree add --no-checkout -b swamp swamp &&
>   ! test -e swamp/init.t &&
> -- 
> 2.15.1.502.gccaef8de57
> 

-- 
Brandon Williams


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

2017-12-11 Thread Junio C Hamano
Eric Sunshine  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 
> Signed-off-by: Eric Sunshine 
> ---
>  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(, "%s/objects", src_repo);
> + get_common_dir(, src_repo);
> + strbuf_addstr(, "/objects");
>   add_to_alternates_file(alt.buf);
>   strbuf_release();
>   } else {

Makes sense.  Will queue.

Thanks.