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 v3] worktree add: improve message for ambiguous remote branch name
Date: Mon, 10 Aug 2026 17:03:57 -0700 [thread overview]
Message-ID: <xmqqecg55xqq.fsf@gitster.g> (raw)
In-Reply-To: <pull.2197.v3.git.1786395305884.gitgitgadget@gmail.com> (Yoichi NAKAYAMA via GitGitGadget's message of "Mon, 10 Aug 2026 20:55:05 +0000")
"Yoichi NAKAYAMA via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Yoichi NAKAYAMA <yoichi.nakayama@gmail.com>
>
> When the user runs 'git worktree add x y' command that does not
> exactly say which remote they want to work with, and there is no local
> branch named y, we try to guess which remote by passing y then create
> a new branch named y which tracks the remote branch.
I used x and y as placeholders. The readers would be helped if you
used a more plausible sounding names, e.g., naming directory as
something like foo-dir (the point being 'dir' somewhere in its name)
and naming a branch as something like bar-topic. If this were 'git
worktree add', it is probably more than likely that the destination
directory would begin with ../ to have the new worktree next to the
primary repository we are running in, no?
> If there are multiple remotes that have branch named y, we silently
> gave up, leaving the variable branch intact. This later causes
> creating local branch and worktree not happen, and we end up with
> passing an non-existing branch to lookup_commit_reference_by_name(),
> triggering "invalid reference" error and die.
"This later causes" part still seems a bit too sketchy to help a
totally new reader, even though I've stared at this code long enough
so it would be sufficient for me personally. But these logs are not
about helping me, but helping other developers, so...
> +#define WORKTREE_ADD_AMBIGUOUS_REMOTE_BRANCH_NAME_HINT_TEXT \
> + _("Matched multiple remote tracking branches, you can list them by:\n" \
> + "\n" \
> + " git branch -r --list \"*/%s\"\n" \
> + "\n" \
> + "If you meant to create a worktree from a remote tracking branch on,\n" \
> + "e.g. 'origin', you can do so by:\n" \
> + "\n" \
> + " git worktree add -b %s %s origin/%s\n" \
> + "\n" \
> + "If you'd like to always prefer some remote, e.g. 'origin',\n" \
> + "consider setting checkout.defaultRemote=origin in your config.")
Instead of throwing the problem back to the user with four extra
lines of message telling them how to run 'git branch', I would have
expected this patch to teach unique_tracking_name() to optionally
return the list of remotes with that branch name, and to use that
result in this message. However, if the goal is simply to provide
something better than 'invalid reference', we do not even need to
go that far. Just stating that branch 'y' appears on multiple
remotes and asking them to clarify which one they mean might be a
sufficient improvement.
Could the original request be aiming to create a new worktree with
the HEAD detached at the commit pointed at by the remote-tracking
branch, instead of creating a local branch forked from it? I am
just wondering if "-b %s" is too specific to one possible
interpretation that may contradict to what the user actually wanted
to do.
Thanks.
next prev parent reply other threads:[~2026-08-11 0:04 UTC|newest]
Thread overview: 18+ 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-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 [this message]
2026-08-11 6:31 ` Yoichi Nakayama
2026-08-11 6:35 ` [PATCH v4] " Yoichi NAKAYAMA via GitGitGadget
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=xmqqecg55xqq.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.