On Mon, Jan 18, 2021 at 12:15 AM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: > On Sun, Jan 17, 2021 at 6:43 PM Rafael Silva > <rafaeloliveira.cs@xxxxxxxxx> wrote: > > +test_expect_success '"list" all worktrees --verbose with locked' ' > > + test_when_finished "rm -rf locked out actual expect && git worktree prune" && > > + git worktree add locked --detach && > > + git worktree lock locked --reason "with reason" && > > + test_when_finished "git worktree unlock locked" && > > + echo "$(git -C locked rev-parse --show-toplevel) $(git rev-parse --short HEAD) (detached HEAD)" >expect && > > + printf "\tlocked: with reason\n" >>expect && > > + git worktree list --verbose >out && > > + sed -n "s/ */ /g;/\/locked *[0-9a-f].*$/,/locked: .*$/p" <out >actual && > > + test_cmp actual expect > > +' > > At first, I wondered if we would also want this test to have a > locked-no-reason worktree to ensure that its `locked` annotation stays > on the same line as the worktree, but that's not needed because that > case is already covered by the existing test. Fine. Erm, I think what I said is wrong. There is no existing test to show that `locked` without a reason stays on the same line as the worktree in --verbose mode. So having a locked-no-reason worktree in this test could be beneficial.
