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

[Jasper Mayone <me@jaspermayone.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