On Mon, Sep 28, 2020 at 5:38 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Rafael Silva <rafaeloliveira.cs@xxxxxxxxx> writes:
> > The output of `worktree list` command is extended to mark a locked
> > worktree with `(locked)` text. This is used to communicate to the
> > user that a linked worktree is locked instead of learning only when
> > attempting to remove it.
>
> For this change, it might look like this:
>
> The "git worktree list" shows the absolute path to the working
> tree, the commit that is checked out and the name of the branch.
> It is not immediately obvious which of the worktrees, if any,
> are locked.
>
> "git worktree remove" refuses to remove a locked worktree with
> an error message. If "git worktree list" told which worktrees
> are locked in its output, the user would not even attempt to
> remove such a worktree.
Nicely written. I might end the final sentence like this:
... the user would not even attempt to remove such a worktree or
would know to use `git worktree remove -f -f <path>`.
> > diff --git a/builtin/worktree.c b/builtin/worktree.c
> > @@ -676,8 +676,12 @@ static void show_worktree(struct worktree *wt, int path_maxlen, int abbrev_len)
> > + if (!is_main_worktree(wt) &&
> > + worktree_lock_reason(wt))
> > + strbuf_addstr(&sb, " (locked)");
>
> Is this because for the primary worktree, worktree_lock_reason()
> will always yield true?
>
> ... goes and looks ...
>
> Ah, OK, the callers are not even allowed to ask the question on the
> primary one. That's a bit strange API but OK.
That is indeed a slightly hostile API, and it wouldn't hurt to change
it simply to return 'false' for the main worktree, but that's not
something this patch series need tackle.
