From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Junio C Hamano <gitster@pobox.com>, Git List <git@vger.kernel.org>
Subject: Re: [PATCH 5/6] completion: list existing working trees for 'git worktree' subcommands
Date: Fri, 18 Oct 2019 17:00:06 +0200 [thread overview]
Message-ID: <20191018150006.GD29845@szeder.dev> (raw)
In-Reply-To: <CAPig+cSGXqJuaZPhUhOVX5X=LMrjVfv8ye_6ncMUbyKox1i7QA@mail.gmail.com>
On Thu, Oct 17, 2019 at 02:08:12PM -0400, Eric Sunshine wrote:
> On Thu, Oct 17, 2019 at 1:35 PM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> > Complete the paths of existing working trees for 'git worktree's
> > 'move', 'remove', 'lock', and 'unlock' subcommands.
> > [...]
> > Arguably 'git worktree unlock <TAB>' should only complete locked
> > working trees, but 'git worktree list --porcelain' doesn't indicate
> > which working trees are locked. So for now it will complete the paths
> > of all existing working trees, including non-locked ones as well.
>
> It is a long-standing To-Do[1] for "git worktree list [--porcelain]"
> to indicate whether a worktree is locked, prunable, etc. Looking at
> the implementation of builtin/worktree.c:show_worktree_porcelain(), it
> should be easy enough to add.
I didn't look at the implementation, but only at the docs, which says:
--porcelain
With list, output in an easy-to-parse format for scripts. This
format will remain stable across Git versions and regardless of
user configuration. See below for details.
I'm not sure whether introducing a new boolean attribute (i.e. a line
containing only "locked") would still be considered acceptable, or
would count as changing the format. I can imagine that a too strict
parser would barf upon encountering the unrecognized "locked"
attribute; but yeah, no sensible parser should be that strict IMO.
Furthermore, I'm not sure what to do with the reason for locking. In
general I would think that it makes sense to display the reason in an
easy-to-parse format as well. However, doing so will inherently make
the format less easy to parse, because the reason could span multiple
lines, so without some sort of encoding/escaping it would violate the
"a line per attribute" format.
I would say that this is beyong the scope of this patch series :)
> > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> > @@ -2981,10 +2981,21 @@ _git_whatchanged ()
> > +__git_complete_worktree_paths ()
> > +{
> > + local IFS=$'\n'
> > + __gitcomp_nl "$(git worktree list --porcelain |
> > + sed -n -e '2,$ s/^worktree //p')"
> > +}
>
> I know that the commit message talks about it, but it might deserve an
> in-code comment
OK.
next prev parent reply other threads:[~2019-10-18 15:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 17:34 [PATCH 0/6] completion: improve completion for 'git worktree' SZEDER Gábor
2019-10-17 17:34 ` [PATCH 1/6] t9902-completion: add tests for the __git_find_on_cmdline() helper SZEDER Gábor
2019-10-17 17:34 ` [PATCH 2/6] completion: clean up the __git_find_on_cmdline() helper function SZEDER Gábor
2019-10-17 17:34 ` [PATCH 3/6] completion: return the index of found word from __git_find_on_cmdline() SZEDER Gábor
2019-10-17 17:52 ` Eric Sunshine
2019-10-18 14:37 ` SZEDER Gábor
2019-10-18 21:01 ` Eric Sunshine
2019-12-19 14:39 ` SZEDER Gábor
2019-12-19 14:44 ` SZEDER Gábor
2019-10-17 17:34 ` [PATCH 4/6] completion: simplify completing 'git worktree' subcommands and options SZEDER Gábor
2019-10-17 17:35 ` [PATCH 5/6] completion: list existing working trees for 'git worktree' subcommands SZEDER Gábor
2019-10-17 18:08 ` Eric Sunshine
2019-10-18 15:00 ` SZEDER Gábor [this message]
2019-10-18 20:45 ` Eric Sunshine
2019-10-17 17:35 ` [PATCH 6/6] completion: list paths and refs for 'git worktree add' SZEDER Gábor
2019-12-19 15:09 ` [PATCH v2 0/6] completion: improve completion for 'git worktree' SZEDER Gábor
2019-12-19 15:09 ` [PATCH v2 1/6] t9902-completion: add tests for the __git_find_on_cmdline() helper SZEDER Gábor
2019-12-19 15:09 ` [PATCH v2 2/6] completion: clean up the __git_find_on_cmdline() helper function SZEDER Gábor
2019-12-19 15:09 ` [PATCH v2 3/6] completion: return the index of found word from __git_find_on_cmdline() SZEDER Gábor
2019-12-19 15:09 ` [PATCH v2 4/6] completion: simplify completing 'git worktree' subcommands and options SZEDER Gábor
2019-12-19 15:09 ` [PATCH v2 5/6] completion: list existing working trees for 'git worktree' subcommands SZEDER Gábor
2019-12-19 15:09 ` [PATCH v2 6/6] completion: list paths and refs for 'git worktree add' SZEDER Gábor
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=20191018150006.GD29845@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sunshine@sunshineco.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.