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.