From: Jasper Mayone Date: Mon, 02 Nov 2026 17:57:07 GMT Subject: Re: [PATCH 1/2] worktree remove: refuse a worktree in the middle of a rebase or bisect Message-ID: <20261102175708.75996-1-me@jaspermayone.com> In-Reply-To: Phillip Wood 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 > > 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