Re: [PATCH 1/2] worktree remove: refuse a worktree in the middle of a rebase or bisect

From: Jasper Mayone <me@jaspermayone.com>
Date: Nov 2, 2026, 17:57 UTC
Message-ID: <20261102175708.75996-1-me@jaspermayone.com>
In-Reply-To: <bf554c5f-066c-4e58-a583-0f95aedecf95@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

> Cherry picking or reverting a single commit that contains no new
> changes also looks clean, but there is still a cherry-pick operation
> in progress as CHERRY_PICK_HEAD exists.

[...]

> Fixing that case simply requires us to see if CHERRY_PICK_HEAD, or
> REVERT_HEAD exist.

Good catch. v4 will check for CHERRY_PICK_HEAD and REVERT_HEAD in the worktree's $GIT_DIR as well as the sequencer directory, with a test for a single empty cherry-pick.

>> Helped-by: Phillip Wood <phillip.wood123@gmail.com>
>
> I'm not sure what I've done anything to help with this patch

You are right, your help was on the other patch. I will drop it here.

> A list of the conditions that require --force might make this section
> clearer.

Agreed. I will turn the `remove` description into a list of what makes a worktree unclean (modified or untracked files, submodules, and an operation in progress), and fix the "or" chains and "either" you pointed out.

> If we're running a lot of consecutive commands in a worktree, it is
> clearer to use a subshell

Will do.

> I wonder how hard it would be to extend the "setup" test to create a
> branch that has conflicts when it is applied with am, cherry-pick, or
> rebase, so that we don't have to set up the conflicts in each test.

I will try that for v4. A branch that changes the same line as a commit on top of "init" should give a conflict for all three.

Thanks for the review.

Jasper