Re: [PATCH v2 2/2] worktree: reap ephemeral branches created by "worktree add"

[Phillip Wood <phillip.wood123@gmail.com>]

On 21/10/2026 09:28, Jason Newton wrote:
> Please focus on reviewing, I use mixed but you shouldn't assume which
> parts are and are not llms.
> 
> What you don't realize by working in a silo for a long time is your
> communication skills to external parties gets reduced with jargon and
> nitpicking ; I have the llms both assume you're wrong and right while
> seeing the undesirable behaviors your stances have to the one that I
> know is correct.  You seem overly sensitive to the usage so far. I
> have no tollerance left to give - so stay on point. You should
> consider several harnesses chose not to even go through PRs and work
> around the functionality like grok build did, patching it in
> externally which is kind of nuts - and replicated.  I think it's
> something you should think about the nature of quite a bit.
> 
> As I mentioned, detached IOWs sucks and you shouldn't have bothered
> mentioning it because it fails hard, though it was noted and evaluated
> in earnest for a bad idea - want to go back to the long but more
> neutral form?

I'm afraid this messages falls far short of the standard of constructive 
discussion that is expected on this list. It is perfectly possible to 
disagree with someone without attacking them or telling them what they 
should or should not be doing.

It is clear that you do not like the current behavior of "git worktree 
add", but replying with a generic list of the differences between a 
branch checkout and a detached HEAD and then attacking the reviewer does 
not explain what problem you are trying to solve and is not going to 
convince anyone that this patch is a good idea.

Thanks

Phillip
> -Jason
> 
> 
> On Wed, Oct 21, 2026 at 1:07 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
>>
>> On Wed, Oct 21, 2026 at 3:40 AM Jason Newton <nevion@gmail.com> wrote:>
>>> --detach and an ephemeral branch differ while the worktree exists.
>>>
>>> --detach leaves HEAD with no branch, so status, push, rename,
>>> upstream, and symbolic-ref have nothing to name. An ephemeral
>>> branch is a normal refs/heads/ ref for the life of the worktree.
>>> Commits go on it, and another ref can point at them before
>>> "worktree remove" deletes that branch.
>>>
>>> Deleting the branch that "worktree add <path>" creates today
>>> would change the default, so this has to be opt-in. That opt-in
>>> is not --detach: the worktree stays on a branch until removal.
>>>
>>> These worktrees might be minutes or they might go on for months;
>>> either way they should be easy to use and not require flags to assist
>>>   in the majority of common case behaviors, moreover detached feels
>>> ike a degraded halfway state, frequently allowing a gotcha to strike or
>>>   a loss of a safety like a gc based reap.
>>>
>>> "git worktree remove" does not delete whatever branch a worktree
>>> has checked out. It deletes a branch only when this "git worktree
>>> add" created it by DWIM (the final component of <path>) and recorded
>>> that in worktrees/<id>/owned-branch.
>>>
>>> A branch named with -b/-B, a branch that already existed, and a
>>> detached HEAD are not owned and are not removed. A worktree created
>>> by an older Git has no marker, so removing it still leaves its
>>> branch in place.
>>>
>>> "Unconditional" in the commit means that this one owned branch is
>>> deleted even if it has unmerged commits. --keep-branch turns that
>>> off. "git branch <name> <tip>" before removal keeps the commits on
>>> an ordinary branch; only the owned ref is deleted.
>>>
>>> The call that changes is "git worktree add <path>" with no branch,
>>> followed by "git worktree remove". A caller who wants that branch
>>> to outlive the worktree already has a spelling this series does not
>>> touch: "git worktree add -b <name> <path>", or "git worktree add
>>> <path> <existing>". --detach still creates no branch, so it is not
>>> the same state while the worktree exists.
>>>
>>> Ownership is written only when the worktree is created, so I'll confirm
>>> an older worktree still has no marker after an upgrade.  The branch stays.
>>> Upgrading does not mark a worktree you already have so no upgrade
>>> headaches are expected.
>>
>> Feeding a reviewer's comments into an agent and pasting its
>> LLM-generated response into an email is not a good way to convince
>> project stakeholders that the submission has value. If you can't
>> explain its value in concrete terms in your own words, then you're
>> going to have a hard time eliciting any responses or additional
>> reviewer feedback.
>