All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Yoichi NAKAYAMA via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  Harald Nordgren <haraldnordgren@gmail.com>,
	Yoichi Nakayama <yoichi.nakayama@gmail.com>,
	 "D. Ben Knoble" <ben.knoble@gmail.com>
Subject: Re: [PATCH v6 3/3] worktree add: improve message for ambiguous remote branch name
Date: Thu, 20 Aug 2026 20:54:24 -0700	[thread overview]
Message-ID: <xmqqa4qgruvj.fsf@gitster.g> (raw)
In-Reply-To: <dcb84a69a6a65085d468a0a212cea0281605c5d0.1787259838.git.gitgitgadget@gmail.com> (Yoichi NAKAYAMA via GitGitGadget's message of "Thu, 20 Aug 2026 21:03:58 +0000")

"Yoichi NAKAYAMA via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com>
>
> When the user runs 'git worktree add ../foo-dir bar-topic' command
> that does not exactly say which remote they want to work with, and
> there is no local branch named bar-topic, we try to guess which remote
> by passing bar-topic then create a new branch named bar-topic which
> tracks the remote branch.
>
> If there are multiple remotes that have branch named bar-topic, we
> silently gave up, leaving the variable 'branch' intact.  Then we
> entered the conditional clause 'if (!opts.orphan &&
> !lookup_commit_reference_by_name(branch))' and triggered "invalid
> reference" error.  This error message did not contain enough
> information to resolve the issue where the remote could not be
> guessed.
>
> To improve the situation, we display a hint and a descriptive error
> message and die immediately when multiple matching branches are found.
>
> Signed-off-by: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com>
> ---
>  builtin/worktree.c      | 35 +++++++++++++++++++++++++++++++++--
>  t/t2400-worktree-add.sh |  4 ++--
>  2 files changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> index 22c8e5e131..8286c283e0 100644
> --- a/builtin/worktree.c
> +++ b/builtin/worktree.c
> @@ -788,6 +788,25 @@ static char *dwim_branch(const char *path, char **new_branch)
>  	return NULL;
>  }
>  
> +static void advise_disambiguating_remotes(const char *path, const char *branch,
> +					  const struct string_list *matched_remote_names)
> +{
> +	struct string_list_item *item;
> +
> +	advise(_("Branches with the same name appears in multiple remotes:"));

The subject "Branches" calls for plural verb "appear" (not
"appears").  The same issue appears in [PATCH 2/3].

>  		if (!commit) {
> -			remote = unique_tracking_name(branch, &oid, NULL, NULL);
> +			char *remote;
> +			int num_matches = 0;
> +			struct string_list matched_remote_names = STRING_LIST_INIT_DUP;
> +
> +			remote = unique_tracking_name(branch, &oid, &num_matches,
> +						      &matched_remote_names);
>  			if (remote) {
>  				new_branch = branch;
>  				branch = new_branch_to_free = remote;
> +			} else if (num_matches > 1) {
> +				if (!opts.quiet &&
> +				    advice_enabled(ADVICE_CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME))
> +					advise_disambiguating_remotes(path, branch,
> +								      &matched_remote_names);
> +				die(_("'%s' matched multiple (%d) remote tracking branches"),
> +				    branch, num_matches);
>  			}
> +			string_list_clear(&matched_remote_names, 0);
>  		}

This appears inside "} else if (ac == 2) {" to catch an invocation
like

	git worktree add ../over-there topic-branch

where the origin of topic-branch is ambiguous (in other words,
appears in multiple remotes).  But don't we have the same issue for
1 argument case that appears just above this (ac == 2) case that
handles

	git worktree add ../topic-branch

invocation?  The code reads like:

	} else if (ac < 2) {
		/* DWIM: Guess branch name from path. */
		char *s = dwim_branch(path, &new_branch_to_free);
		if (s)
			branch = branch_to_free = s;
		new_branch = new_branch_to_free;

		/* DWIM: Infer --orphan when repo has no refs. */
		opts.orphan = (!s) && dwim_orphan(&opts, !!opt_track, 1);
	} else if (ac == 2) {

where the branch name "topic-branch" is guessed from the path by
calling dwim_branch(), and we would get NULL in s.  branch is left
as-is, so it becomes "HEAD" that was assigned much earlier in the
same function.

        branch = ac < 2 ? "HEAD" : av[1];

We would create a new directory in ../topic-branch next door, and
then which branch would we check out?  Would dwim_orphan() kick in?

Perhaps we want to update that code path to disambiguate the same way?

> diff --git a/t/t2400-worktree-add.sh b/t/t2400-worktree-add.sh
> index 87b926728a..5c105cf252 100755
> --- a/t/t2400-worktree-add.sh
> +++ b/t/t2400-worktree-add.sh
> @@ -624,12 +624,12 @@ test_expect_success '"add" <path> <branch> dwims' '
>  test_expect_success '"add" <path> <branch> dwims with checkout.defaultRemote' '
>  	test_when_finished rm -rf repo_upstream repo_dwim foo &&
>  	setup_remote_repo repo_upstream repo_dwim &&
> -	git init repo_dwim &&
>  	(
>  		cd repo_dwim &&
>  		git remote add repo_upstream2 ../repo_upstream &&
>  		git fetch repo_upstream2 &&
> -		test_must_fail git worktree add ../foo foo &&
> +		test_must_fail git worktree add ../foo foo 2>error.actual &&
> +		test_grep "matched multiple (2) remote tracking branches" error.actual &&
>  		git -c checkout.defaultRemote=repo_upstream worktree add ../foo foo &&
>  		git status -uno --porcelain >status.actual &&
>  		test_must_be_empty status.actual

      reply	other threads:[~2026-08-21  3:54 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-08  8:21 [PATCH] worktree add: improve message for ambiguous remote branch name Yoichi NAKAYAMA via GitGitGadget
2026-08-08 17:00 ` Junio C Hamano
2026-08-08 21:57   ` Junio C Hamano
2026-08-09  7:45     ` Harald Nordgren
2026-08-09 18:19       ` Junio C Hamano
2026-08-10 10:12         ` Harald Nordgren
2026-08-09 18:17     ` Junio C Hamano
2026-08-10 13:04     ` Yoichi Nakayama
2026-08-10 13:00   ` Yoichi Nakayama
2026-08-10 13:07 ` D. Ben Knoble
2026-08-10 13:35   ` Yoichi Nakayama
2026-08-10 15:06     ` Junio C Hamano
2026-08-10 21:36   ` Yoichi Nakayama
2026-08-11 16:38     ` Ben Knoble
2026-08-12 13:14       ` Yoichi Nakayama
2026-08-10 15:07 ` [PATCH v2] " Yoichi NAKAYAMA via GitGitGadget
2026-08-10 20:55 ` [PATCH v3] " Yoichi NAKAYAMA via GitGitGadget
2026-08-11  0:03   ` Junio C Hamano
2026-08-11  6:31     ` Yoichi Nakayama
2026-08-12 19:22       ` Junio C Hamano
2026-08-15  4:36         ` Yoichi Nakayama
2026-08-11  6:35 ` [PATCH v4] " Yoichi NAKAYAMA via GitGitGadget
2026-08-19 12:50 ` [PATCH v5 0/2] " Yoichi NAKAYAMA via GitGitGadget
2026-08-19 12:50   ` [PATCH v5 1/2] checkout: " Yoichi NAKAYAMA via GitGitGadget
2026-08-19 22:54     ` D. Ben Knoble
2026-08-20  2:18       ` Junio C Hamano
2026-08-20 15:41         ` Yoichi Nakayama
2026-08-19 12:50   ` [PATCH v5 2/2] worktree add: " Yoichi NAKAYAMA via GitGitGadget
2026-08-20 21:03 ` [PATCH v6 0/3] " Yoichi NAKAYAMA via GitGitGadget
2026-08-20 21:03   ` [PATCH v6 1/3] checkout: extract function to display advice for ambiguous remotes Yoichi NAKAYAMA via GitGitGadget
2026-08-20 21:03   ` [PATCH v6 2/3] checkout: improve message for ambiguous remote branch name Yoichi NAKAYAMA via GitGitGadget
2026-08-20 21:03   ` [PATCH v6 3/3] worktree add: " Yoichi NAKAYAMA via GitGitGadget
2026-08-21  3:54     ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqa4qgruvj.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ben.knoble@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=haraldnordgren@gmail.com \
    --cc=yoichi.nakayama@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.