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

Le 10 août 2026 à 17:36, Yoichi Nakayama [off-list ref] a écrit :

On Mon, Aug 10, 2026 at 10:08 PM D. Ben Knoble [off-list ref] wrote:

quoted

quoted

-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.