Re: [RFC PATCH 1/2] worktree: teach `list` to mark locked worktree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux