From: Junio C Hamano <gitster@pobox.com>
To: Gabriel Scherer <gabriel.scherer@inria.fr>
Cc: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>,
git@vger.kernel.org, "D. Ben Knoble" <ben.knoble@gmail.com>,
Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH 1/3] checkout: provide hint when failing due to another worktree
Date: Mon, 15 Sep 2025 01:53:01 -0700 [thread overview]
Message-ID: <xmqqikhkhzbm.fsf@gitster.g> (raw)
In-Reply-To: <d44109a1-0ff5-49f8-885b-9aae195ec492@inria.fr> (Gabriel Scherer's message of "Sun, 14 Sep 2025 09:50:57 +0200")
Gabriel Scherer <gabriel.scherer@inria.fr> writes:
> In my in-progress version of the patch, the reworded advice is as follows:
>
> fatal: 'foo' is already used by worktree at '/home/gasche/Prog/foo'
> hint: If you want to proceed anyway, try again with
> --ignore-other-worktrees.
> hint: Changes to the branch will also impact the other worktrees.
> hint:
> hint: If you want to detach HEAD at that branch, try again with the
> --detach option.
To those who _need_ these hint messages (in other words, those who
cannot choose the right way to do what they wanted to do without
getting hints), I suspect think "if you want to proceed anyway",
"impact" and "if you want to" are not concrete enough to help them
make the right choices.
"If you want to proceed anyway"---of course they all do, because
they do not know what risks they are taking, and this message does
not tell them about. So that isn't very helpful message.
Changes to the branch would not change the index or any files in the
working tree of other worktree, leading these users to think that
they safely live in two separte isolated worlds in these two
separate worktrees. Is it clear to them that the "impact" you are
talking about is exactly the fact that these changes are *NOT*
propagated to other worktree?
Then you have "if you want to" without telling the readers why they
should "want to" (or not) detach. Which is not all that helpful.
Why should I go into the scary sounding "detached HEAD" mode? For
what for? If a user can answer that question themselves, they do
not even need that hint.
I think the message should help the readers eventually realize the
following things to make intelligent decisions. Making them short
to fit in the "hint:" messages is left as an exercise ;-)
- 'foo' is already in use and in which worktree. Your message
"fatal:" is very clear and is good.
- if you checkout 'foo' here and start growing or otherwise
updating the history of 'foo' in this worktree, the index and the
working tree files of other worktree(s) will go out of sync with
the tip of 'foo'. if they 'git commit' from that state, for
example, it is very likely that they will record a change that
reverts your changes from the history of 'foo', and you do not
want that.
- if you want to grow history of 'foo' in potentially different
direction from what the other worktree with 'foo' is working on,
you are better off creating a separte branch 'foo2', with
anticipation that you'll eventually merge them together.
- if you only want to browse the files or build but have no
intention to change the files or make commits, then you can have
the HEAD of this working tree detached at the commit at the tip
of 'foo'. An advantage of this approach is that it will keep you
honest, if you know that you are *not* on 'foo', but not on any
branch, it would discourage you from making commits and
disturbing the other working tree. Another advantage is that
when you do need to make commits (perhaps while you are browsing
the files, you may find small typos you want to fix), you can at
that time run "git checkout -b foo-typofix" to create a new
branch and commit, without disturbing the other worktree that
have 'foo' checked out.
next prev parent reply other threads:[~2025-09-15 8:53 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-13 14:13 [PATCH 0/3] extend --ignore-other-worktrees to 'rebase', add hints Gabriel Scherer
2025-09-13 14:13 ` [PATCH 1/3] checkout: provide hint when failing due to another worktree Gabriel Scherer
2025-09-13 20:55 ` Kristoffer Haugsbakk
2025-09-14 7:50 ` Gabriel Scherer
2025-09-15 8:53 ` Junio C Hamano [this message]
2025-09-15 19:52 ` Gabriel Scherer
2025-09-16 5:32 ` Junio C Hamano
2025-09-17 14:17 ` Junio C Hamano
2025-09-17 15:25 ` Gabriel Scherer
2025-09-19 14:13 ` Phillip Wood
2025-09-14 19:03 ` Ben Knoble
2025-09-14 19:06 ` Ben Knoble
2025-09-14 19:32 ` Kristoffer Haugsbakk
2025-09-13 14:13 ` [PATCH 2/3] rebase: support --ignore-other-worktrees Gabriel Scherer
2025-09-15 10:09 ` Phillip Wood
2025-09-15 16:23 ` Junio C Hamano
2025-09-13 14:13 ` [PATCH 3/3] rebase: hint when failing on branch used by another worktree Gabriel Scherer
2025-09-13 19:30 ` [PATCH 0/3] extend --ignore-other-worktrees to 'rebase', add hints Ben Knoble
2025-09-13 20:02 ` Gabriel Scherer
2025-09-15 10:09 ` Phillip Wood
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=xmqqikhkhzbm.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ben.knoble@gmail.com \
--cc=gabriel.scherer@inria.fr \
--cc=git@vger.kernel.org \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=phillip.wood@dunelm.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).