All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder@ira.uka.de>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH 6/6] completion: clarify ls-tree, archive, show completion
Date: Mon, 3 Jun 2013 21:25:55 +0200	[thread overview]
Message-ID: <20130603192555.GK2192@goldbirke> (raw)
In-Reply-To: <1370181822-23450-7-git-send-email-artagnon@gmail.com>

On Sun, Jun 02, 2013 at 07:33:42PM +0530, Ramkumar Ramachandra wrote:
> Currently, the 'git ls-tree', 'git archive', and 'git show' completions
> use __git_complete_file (aliased to __git_complete_revlist_file).
> 
> In the case of 'git ls-tree' and 'git archive', they necessarily require
> a tree-ish argument (and optionally a pathspec filter, or "file
> argument"):
> 
>   $ git ls-tree hot-branch git.c
>   $ git archive HEAD~4 git.c
> 
> So, __git_complete_file is a misleading name.
> 
> In the case of 'git show', it can take a pathspec and default the
> revision to HEAD like:
> 
>   $ git show git.c
> 
> (which is useful if git.c was modified in HEAD)
> 
> However, this usage is not idiomatic at all.  The more common usage is
> like:
> 
>   $ git show HEAD~1
>   $ git show origin/pu:git.c
> 
> So, __git_complete_file is again a poor name.
> 
> Replace these three instances of __git_complete_file with
> __git_complete_revlist_file, without making any functional changes.
> 
> Remove __git_complete_file, as it has no other callers.
> 

Well, people out there might have completion scriplets for their
aliases or custom git commands which use __git_complete_file().
Removing this function would break those scripts.

Arguably the name of __git_complete_file() could describe better what
the function does, or what it did, i.e. it used to provide completion
for the master:Doc<TAB> notation.  But that's only the name.  Since
both git ls-tree and git archive understand this notation, calling the
helper for master:Doc<TAB> in their completion functions is not
misleading at all.

Now, __git_complete_revlist_file() provides completion both for this
master:Doc<TAB> notation and for revision ranges, i.e. for
master..n<TAB> and master...n<TAB>.  However, since neither git
ls-tree nor git archive accept revision ranges, calling
__git_complete_revlist_file() in their completion function would be
misleading.

git show is special, as it understands both the master:Doc<TAB>
notation and revision ranges, and even the combination of the two, so
calling __git_complete_revlist_file() there would indeed be better.


Gábor

  parent reply	other threads:[~2013-06-03 19:26 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-02 14:03 [PATCH 0/6] Minor prompt, completion cleanups Ramkumar Ramachandra
2013-06-02 14:03 ` [PATCH 1/6] prompt: don't scream continuation state Ramkumar Ramachandra
2013-06-03  8:58   ` Thomas Rast
2013-06-03  9:47     ` Ramkumar Ramachandra
2013-06-03 21:15       ` Jeff King
2013-06-04  3:44         ` Ramkumar Ramachandra
2013-06-04  4:38           ` Jeff King
2013-06-04  5:59             ` Junio C Hamano
2013-06-03 17:23     ` Junio C Hamano
2013-06-02 14:03 ` [PATCH 2/6] completion: add common options for rev-parse Ramkumar Ramachandra
2013-06-07 15:33   ` Ramkumar Ramachandra
2013-06-02 14:03 ` [PATCH 3/6] completion: add common options for blame Ramkumar Ramachandra
2013-06-03  9:03   ` Thomas Rast
2013-06-03  9:32     ` Ramkumar Ramachandra
2013-06-03 18:07       ` SZEDER Gábor
2013-06-03 18:34         ` Junio C Hamano
2013-06-06  9:58       ` Peter Krefting
2013-06-03 17:24     ` Junio C Hamano
2013-06-02 14:03 ` [PATCH 4/6] completion: correct completion for format-patch Ramkumar Ramachandra
2013-06-02 17:20   ` Felipe Contreras
2013-06-02 17:29     ` Ramkumar Ramachandra
2013-06-02 14:03 ` [PATCH 5/6] completion: clarify difftool completion Ramkumar Ramachandra
2013-06-03 17:29   ` Junio C Hamano
2013-06-02 14:03 ` [PATCH 6/6] completion: clarify ls-tree, archive, show completion Ramkumar Ramachandra
2013-06-03 17:33   ` Junio C Hamano
2013-06-04  3:49     ` Ramkumar Ramachandra
2013-06-04  6:01       ` Junio C Hamano
2013-06-03 17:58   ` Junio C Hamano
2013-06-03 19:25   ` SZEDER Gábor [this message]
2013-06-07 17:21     ` Ramkumar Ramachandra
2013-06-07 18:36       ` Junio C Hamano
2013-06-07 18:45       ` SZEDER Gábor
2013-06-09 20:56     ` Junio C Hamano

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=20130603192555.GK2192@goldbirke \
    --to=szeder@ira.uka.de \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    /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.