Subject: Re: [PATCH 2/3] worktree: warn when removing a worktree with orphan commits

From: Junio C Hamano <[email-masked]>
Date: Thu, 27 Apr 2023 17:49:44 -0700

Eric Sunshine <[email-masked]> writes:

> There may be a misunderstanding here due to the unfortunate
> construction of Rubén's example which muddles together the output of
> `git worktree add` and `git worktree remove`. For clarity, his example
> should probably have been written:
>
>   $ git worktree add test --detach
>   Preparing worktree (detached HEAD 2efe05c)
>   HEAD is now at 2efe05c commit-a
>   $ git worktree remove test
>   HEAD position was 2efe05c commit-a
>
> although showing only the `git worktree remove` command would probably
> have been even clearer.

Ah, you are absolutely right.

My "huh?" against the apparent inconsistency between "checkout" and
"worktree" regarding the order of "this is the end result" vs "this
is what we left behind" does not exist, as "worktree remove" does
not involve being newly on a detached HEAD and it is the one that
may introduce a newly abandoned line of history.  So everything
makes sense.

> Such example output does a good job of arguing in favor of your
> suggestion to use phrasing which is more alarming:
>
>   $ git checkout -
>   Commit 2efe05c "commit-a" left dangling
>   HEAD is now at 7906992 commit-b
>
>   $ git worktree remove test
>   Commit 2efe05c "commit-a" left dangling
>
> (Hopefully someone can come up with better wording than "About to lose
> history leading to" and "Commit ... left dangling", neither of which
> sound quite right.)

Yup, I am obviously worse at phrasing this than you are ;-) We'd
need a good wording that is alarming, even for those who squelch
most of the warning given via the advise system, without becoming
too verbose.

Thanks.