Re: [PATCH] sha1-name.c: for ":/", find detached HEAD commits

[Duy Nguyen <pclouds@gmail.com>]

On Wed, Jul 11, 2018 at 7:20 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Duy Nguyen <pclouds@gmail.com> writes:
>
> >> diff --git a/sha1-name.c b/sha1-name.c
> >> index 60d9ef3c7..641ca12f9 100644
> >> --- a/sha1-name.c
> >> +++ b/sha1-name.c
> >> @@ -1650,6 +1650,7 @@ static int get_oid_with_context_1(const char *name,
> >>                         struct commit_list *list = NULL;
> >>
> >>                         for_each_ref(handle_one_ref, &list);
> >> +                       head_ref(handle_one_ref, &list);
> >
> > When multiple worktrees are used, should we consider all HEADs or just
> > current worktree's HEAD?
>
> Does for_each_ref() iterate over per-worktree refs (like "bisect",
> perhaps)?

No.

> If so, then looking in different worktree's HEADs would
> make sense, and otherwise not.
>
> I would think that the whole point of detaching HEAD in a separate
> worktree is that you can avoid exposing the work you do while
> detached to other worktrees by doing so, so from that point of view,
> I would probably prefer :/ not to look into other worktrees, but
> that is not a very strong preference.

Yeah at least for me worktrees are still quite isolated. Occasionally
I need to peek in a worktree from another one (e.g. if I want to run
tests on current HEAD but do not want to wait for it to finish, I'll
make a new worktree, checking out the same head and run tests there)
but it's really rare. So yeah maybe it's best to stick to current
worktree's HEAD only. At least until someone finds a good case for it.

> If peeking all over the place
> is easier to implement, then a minor information leaking is not
> something I'd lose sleep over.
>
> Thanks for bringing up an interesting issue.
-- 
Duy