Re: [PATCH v2 1/1] worktree: teach `list` to annotate locked worktree

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

 



On Sat, Oct 10, 2020 at 2:56 PM Rafael Silva
<rafaeloliveira.cs@xxxxxxxxx> wrote:
> 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 or would know how to use
> `git worktree remove -f -f <path>`

I would drop "how" from "would know how to" so it instead reads "would
know to" since seeing the `locked` annotation only lets the user know
that removal must be forced; the `locked` annotation doesn't teach the
user _how_ to remove the worktree using force. But, perhaps, my
original suggestion[1], which did not use "how", was confusing. Maybe
it could be worded instead:

    ... not even attempt to remove such a worktree, or would
    realize that `git worktree remove -f -f <path>` is required.

Anyhow, this is a very minor nit about the commit message; not
necessarily worth a re-roll. More comments below...

[1]: https://lore.kernel.org/git/CAPig+cQHDuWy1vc_ngXbMQZQ=a9fd6S5_cCU-2sb_+Te5aEOhw@xxxxxxxxxxxxxx/

> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> @@ -97,7 +97,8 @@ list::
>  List details of each working tree.  The main working tree is listed first,
>  followed by each of the linked working trees.  The output details include
>  whether the working tree is bare, the revision currently checked out, and the
> -branch currently checked out (or "detached HEAD" if none).
> +branch currently checked out (or "detached HEAD" if none). For a locked
> +worktree the `locked` annotation is also shown.

I might have dropped the "and" in the final context line and instead
written this as:

    ... branch currently checked out (or "detached HEAD" if none),
    and "locked" if the worktree is locked.

But not worth a re-roll.

> diff --git a/builtin/worktree.c b/builtin/worktree.c
> @@ -676,8 +676,11 @@ static void show_worktree(struct worktree *wt, int path_maxlen, int abbrev_len)
>                 } else
>                         strbuf_addstr(&sb, "(error)");
>
> +       if (!is_main_worktree(wt) && worktree_lock_reason(wt))
> +               strbuf_addstr(&sb, " locked");

I was going to ask if "locked" should be localizable like this:

    strbuf_addf(&sb, " %s", _("locked"));

but I see that none of the other words ("bare", "detached", "error")
in this function are localizable, so this is fine as-is.

However, all of the other human-consumable text emitted by "git
worktree" is localizable, so making these strings localizable, as
well, is something that can be added to a To-Do list. Note that I'm
talking only about human-consumable "git worktree list" output, not
porcelain format. Also, I'm not suggesting you tackle it, and it's
certainly not something that this patch or patch series needs to do;
just something which someone can tackle in the future.

> diff --git a/t/t2402-worktree-list.sh b/t/t2402-worktree-list.sh
> @@ -61,6 +61,16 @@ test_expect_success '"list" all worktrees --porcelain' '
> +test_expect_success '"list" all worktress with locked annotation' '
> +       test_when_finished "rm -rf locked unlocked out && git worktree prune" &&
> +       git worktree add --detach locked master &&
> +       git worktree add --detach unlocked master &&
> +       git worktree lock locked &&
> +       git worktree list >out &&
> +       grep "/locked *[0-9a-f].* locked" out &&
> +       ! grep "/unlocked *[0-9a-f].* locked" out
> +'

These grep invocations are a bit loose, thus concern me a little bit.

First, in Junio's original example of using grep[2], he had two spaces
after the path component, not one as you have here. The two spaces in
the regex ensure that there is at least one space separating `/locked`
and `/unlocked` from the OID hex string, whereas with just one space
in the regex, as is done here, the space following the path component
is entirely optional (thus is a less desirable regex).

Second, because these regexes are not anchored, they could match with
a false-positive if the person's TRASH_DIRECTORY path is something
like `/home/proj/unlocked dead locked/git/t/...`. If you anchor the
pattern with `$`, then this problem goes away:

    grep "/locked  *[0-9a-f].* locked$" out &&
    ! grep "/unlocked  *[0-9a-f].* locked$" out

Third, this is checking only that the first character following the
path component is a hex digit but then accepts _anything_ before
"locked". The regex can be tightened to allow only hex digits:

    grep "/locked  *[0-9a-f][0-9a-f]* locked$" out &&
    ! grep "/unlocked  *[0-9a-f][0-9a-f]* locked$" out

[2]: https://lore.kernel.org/git/xmqq3631lg8f.fsf@xxxxxxxxxxxxxxxxxxxxxx/



[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