Re: [PATCH v2 6/6] worktree: teach `list` verbose mode
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Jan 18, 2021, 19:40 UTC
- Message-ID
- <CAPig+cTGZPKSb6iJKM=sY22QirhEQX7+K08cGqru=Pp6m4QXxw@mail.gmail.com>
- In-Reply-To
- <CAPig+cQ4jeSkOLb-Ski0G2tvafxh0Jjv+ObB7ZkbcryVYedGZQ@mail.gmail.com>
On Mon, Jan 18, 2021 at 12:15 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
Show 18 quoted lines
> On Sun, Jan 17, 2021 at 6:43 PM Rafael Silva > <rafaeloliveira.cs@gmail.com> 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.