git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.


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