On Thu, Apr 21, 2016 at 1:04 AM, Junio C Hamano <gits...@pobox.com> wrote:
>> diff --git a/builtin/checkout.c b/builtin/checkout.c
>> index efcbd8f..6041718 100644
>> --- a/builtin/checkout.c
>> +++ b/builtin/checkout.c
>> @@ -1111,7 +1111,7 @@ static int checkout_branch(struct checkout_opts *opts,
>> char *head_ref = resolve_refdup("HEAD", 0, sha1, &flag);
>> if (head_ref &&
>> (!(flag & REF_ISSYMREF) || strcmp(head_ref, new->path)))
>> - die_if_checked_out(new->path);
>> + die_if_checked_out(new->path, 1);
>> free(head_ref);
>> }
>
> So the idea is "if the branch is checked out (or "being worked on"
> even if technically the HEAD is detached, like with 'rebase')
> anywhere, callers of die-if-checked-out in general want to die; but
> for this caller, it is OK if the place the branch is checked out or
> being worked on is in this repository"?
>
> I understand die_if_checked_out() taking that "ignore this one" bit
> may be sensible, but I do not understand why find_shared_symref()
> needs to be told about it. The change makes the meaning of the
> find_shared_symref() function unclear. It used to mean "This
> symbolic ref cannot point at the same ref in different worktrees, so
> for a given pair of a symbolic ref and a concrete ref, there can be
> at most one worktree in which the symbolic ref points at that ref".
> That is already a mouthful. As the worktree structure already have
> "Am I the current worktree?" bit, "ignore" logic can easily be done
> inside die_if_checked_out() and that would help find_shared_symref()
> stay simpler and more focused function, no?
That was the intention when I made find_shared_symref() return struct
worktree * instead of char *. I forget why I changed my mind and not
do so. The only case when find_shared_symref should do this is when a
ref is shared twice, then we need to ignore current worktree from
inside the loop. But that can't happen. Will move this
ignore-current-worktree test to die_if_checked_out().
--
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
