git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Rafael Silva <rafaeloliveira.cs@gmail.com>
Cc: Git List <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2 1/1] worktree: teach `list` to annotate locked worktree
Date: Sun, 11 Oct 2020 02:26:31 -0400	[thread overview]
Message-ID: <CAPig+cTq5tz8m0bCJ3GtCa9yzOMNvd7j4fSJNwO9xjqkfK+YOg@mail.gmail.com> (raw)
In-Reply-To: <20201010185521.23032-2-rafaeloliveira.cs@gmail.com>

On Sat, Oct 10, 2020 at 2:56 PM Rafael Silva
<rafaeloliveira.cs@gmail.com> 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@mail.gmail.com/

> 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@gitster.c.googlers.com/

  reply	other threads:[~2020-10-11  6:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-28 15:49 [RFC PATCH 0/2] teach `worktree list` to mark locked worktrees Rafael Silva
2020-09-28 15:49 ` [RFC PATCH 1/2] worktree: teach `list` to mark locked worktree Rafael Silva
2020-09-28 21:37   ` Junio C Hamano
2020-09-29 21:36     ` Rafael Silva
2020-09-30  7:35     ` Eric Sunshine
2020-09-28 15:49 ` [RFC PATCH 2/2] t2402: add test to locked linked worktree marker Rafael Silva
2020-09-28 21:54   ` Junio C Hamano
2020-09-29 21:37     ` Rafael Silva
2020-09-30  8:06   ` Eric Sunshine
2020-09-28 21:19 ` [RFC PATCH 0/2] teach `worktree list` to mark locked worktrees Junio C Hamano
2020-09-29 21:35   ` Rafael Silva
2020-09-30  7:19 ` Eric Sunshine
2020-10-02 16:28   ` Rafael Silva
2020-10-09 22:50     ` Eric Sunshine
2020-10-10 19:06       ` Rafael Silva
2020-10-10 18:55 ` [PATCH v2 0/1] Teach "worktree list" to annotate " Rafael Silva
2020-10-10 18:55   ` [PATCH v2 1/1] worktree: teach `list` to annotate locked worktree Rafael Silva
2020-10-11  6:26     ` Eric Sunshine [this message]
2020-10-11  6:34       ` Eric Sunshine
2020-10-11 10:04       ` Rafael Silva
2020-10-11 10:11   ` [PATCH v3 0/1] Teach "worktree list" to annotate locked worktrees Rafael Silva
2020-10-11 10:11     ` [PATCH v3] worktree: teach `list` to annotate locked worktree Rafael Silva
2020-10-12  2:24       ` Eric Sunshine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPig+cTq5tz8m0bCJ3GtCa9yzOMNvd7j4fSJNwO9xjqkfK+YOg@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=rafaeloliveira.cs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).