Re: [PATCH] worktree add: improve message for ambiguous remote branch name

On Wed, Aug 12, 2026 at 1:38 AM Ben Knoble <[email protected]> wrote:
>
>
> >
> > Le 10 août 2026 à 17:36, Yoichi Nakayama <[email protected]> a écrit :
> >
> > On Mon, Aug 10, 2026 at 10:08 PM D. Ben Knoble <[email protected]> wrote:
> >>> -static char *dwim_branch(const char *path, char **new_branch)
> >>> +static char *dwim_branch(const struct add_opts *opts, const char *path, char **new_branch)
> >>> {
> >>>        int n;
> >>>        int branch_exists;
> >>> @@ -781,8 +791,14 @@ static char *dwim_branch(const char *path, char **new_branch)
> >>>
> >>>        *new_branch = branchname;
> >>>        if (guess_remote) {
> >>> +               int num_matches = 0;
> >>>                struct object_id oid;
> >>> -               char *remote = unique_tracking_name(*new_branch, &oid, NULL);
> >>> +               char *remote = unique_tracking_name(*new_branch, &oid, &num_matches);
> >>> +               if (!opts->quiet && !remote && num_matches > 1) {
> >>> +                       if (advice_enabled(ADVICE_CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME))
> >>> +                               advise(_(message_advice_ambiguous_remote_tracking_branch));
> >>> +                       warning(_("'%s' matched multiple (%d) remote tracking branches\n"), branchname, num_matches);
> >>> +               }
> >>>                return remote;
> >>>        }
> >>>        return NULL;
> >>
> >> I suppose the extra warning won't hurt anyone's workflow :) so that's good.
> >
> > I removed the change (advise and warn) here in the latest patch. But I am still
> > wondering what I should do. I think a warning would be excessive if
> > there is no match,
> > but the user might want to know if there are multiple matches.
> >
> > Thanks,
> > --
> > Yoichi NAKAYAMA
>
> Sorry if I was unclear: I don’t know what hits this particular code path offhand, and I don’t think adding the warning is wrong! I meant « as opposed to dying, a warning won’t break anyone but will let them know of potentially unintended consequences », maybe.
>
> I’m not particularly invested in how we signal ambiguity, but if we don’t have a documented policy for resolving it in a particular way then I agree we should signal it.

Thank you for the additional information. I think the intention behind your
comment was clear. The reason I was wondering was simply that I hadn't yet
found a clear direction for what I should do.

The `git worktree add --guess-remote ../foo` command (without <commit-ish>) is
designed to successfully create the worktree even if the guess fails.
If we are to
issue a warning and advice, we need to indicate what to do next, given that the
worktree and the branch has already been created. It would be something like
    git -C ../foo reset –hard origin/foo
    git -C ../foo branch –set-upstream-to=origin/foo
but they are too complicated. So I now think it is a valid choice to
interpret the
behavior as normal and refrain from issuing a warning or advice.

Thanks,
-- 
Yoichi NAKAYAMA