From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16033 invoked by alias); 16 Aug 2017 04:37:54 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41551 Received: (qmail 20696 invoked by uid 1010); 16 Aug 2017 04:37:54 -0000 X-Qmail-Scanner-Diagnostics: from out1-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(66.111.4.25):SA:0(-2.6/5.0):. Processed in 5.001588 secs); 16 Aug 2017 04:37:54 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=lgkrvID2xxvRH9K+JJkjAZFfZFMqsOp5ak67aZXGVfc=; b=nHR7Q/pV cuYSV7nmZRPyZ3lpGMdxs0ehPINqI3OGY/PZAWN5cvysBti/3O+VSJvvxUDEetyD XV/MLnIhP/6JgYyT4twwyvwWqtVn+8CZjpGvnoBcaRTQQszof3y12sXB/YIchAvS YKnyTBnSGNFODpzLrwMBoJ3xAf1Qs3bFm/kJPOPg+NAy0ftuNS11BZluclbmaNHL 9LxiuHIZCrjttqVaeRdDlOMY07o8LPYaFV8/raXmqhbdTV1Xr7PhTN/09RZWUXIm 0/Nt5YXv/SYGpYVP+EyjPNI3Af/aW8DVfpDrah58e0Y0vckApCbxN//s8xVFI/0d jztFUq62Uw4WTQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=lgkrvID2xxvRH9K+JJkjAZFfZFMqsOp5ak67aZXGVfc=; b=cyZqPZQ6 uzW1u/I3Asof4ItUxsntfUvwsn1Kcuv3oQH5f16jHdF8mXTVYeDqH0rWA2MmCNx4 fWA/PshthHZ4Gd72MOk0ayoLJUh51ydmnCvs+ko6Nkru1ybvoXSVn4e4uIu0dGwt atp1tDTH77vpim9Ccyz+y8KQ0bcR8iK2aP2i+WK7kfVO5U0PKkjlQZB+IumzYZnh V0yHcXztVYyp3pyJYG1j4mOShWuBl728WW4R82X+NUZ7ibtuyz4akSUi/7L0joyN 4YnvWyAz4ZxsDGQchpSR95hM2qo7VlqLay3ADKgICyL2S32Q7Mudn/3I6B13/fcO +biwV26t6xhMwg== X-ME-Sender: X-Sasl-enc: gXOSXtIVJQf3NBl6VJYbrpqOGxefvbSDY5cuYk4MZAOt 1502857579 Date: Wed, 16 Aug 2017 04:26:17 +0000 From: Daniel Shahaf To: zsh-workers@zsh.org Subject: Re: git worktree add /foo Message-ID: <20170816042617.lud425bn2ycahy5d@tarpaulin.shahaf.local2> References: <20170809193113.3gjq3ezigb6yvdu4@tarpaulin.shahaf.local2> <15766.1502711853@thecus.kiddle.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <15766.1502711853@thecus.kiddle.eu> User-Agent: NeoMutt/20170113 (1.7.2) Oliver Kiddle wrote on Mon, Aug 14, 2017 at 13:57:33 +0200: > On 9 Aug, Daniel Shahaf wrote: > > The second argument to 'git worktree add' can be any committish. That > > committish becomes HEAD of the new worktree, and if it's a branch name, > > then that branch becomes the current branch of the new worktree, else > > the new worktree starts as a detached HEAD. > > > > How should that be completed? > > > > Currently it's completed as follows: > > > > +++ b/Completion/Unix/Command/_git > > @@ -2026,11 +2026,7 @@ _git-worktree() { > > curcontext=${curcontext%:*}-$line[1]: > > case $line[1] in > > (add) > > if (( $words[(I)--detach] )); then > > args=( ':commit:__git_commits' ) > > else > > args=( ':branch:__git_branch_names' ) > > fi > > I can't remember why it was done this way but I'm wondering if the > two halves of the if…else…fi are the opposite way around from the > intention. Specifying --detach would be superfluous for anything but > a branch because it is the default for any other committish so after > --detach there is sense in only completing branches. +1 > I often apply logic such as this but it might not always be helpful, > such as if --detach comes from an alias. I don't understand. Firstly, both zsh aliases and git aliases are 'seen through' in completion; secondly, the perfect shouldn't be the enemy of the good. > Otherwise, as you say, any committish is valid and our usual approach > is to just complete them all and expect user's to set tag-order to give > preference to the matches they find most useful. I suggested years back > that we perhaps add a mechanism for giving a default tag-order and > perhaps should consider it again. Let's collect a few such settings before we invent a mechanism; it's easier to invent when there are concrete details to work with. To start with, here's one style I use: # Prefer recent commit object name completion zstyle ':completion::complete:git-(format-patch|send-email):argument-1:' group-order commits > > I see __git_recent_branches but it's not precisely what I have in mind. > > What would be useful in this case? Just __git_branch_names — namely, names of local branches — is exactly what I was after. (Don't know how I managed to miss it) So, yes, reversing the if and adding a tag-order/group-order style should suffice. Additionally, it would be nice if the group description said "(alternatively specify name of new branch)" like _mkdir does. Thanks, Daniel