git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder@ira.uka.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Shawn O. Pearce" <spearce@spearce.org>, <git@vger.kernel.org>,
	Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH] completion: complete "git diff ...branc<TAB>"
Date: Thu, 24 Feb 2011 16:13:28 +0100	[thread overview]
Message-ID: <20110224151328.GB14720@neumann> (raw)
In-Reply-To: <7vlj1677gz.fsf@alter.siamese.dyndns.org>

Hi,


On Wed, Feb 23, 2011 at 01:43:08PM -0800, Junio C Hamano wrote:
> While doing a final sanity check before merging a topic Bsomething, it is
> a good idea to review what damage Bsomething branch would make, by running:
> 
>     $ git diff ...Bsomething
> 
> I however find myself often typing "git diff ...B<TAB>", seeing nothing
> happening and then repeatedly hitting <TAB>, saying "huh? <TAAAAAAAAB>!".
> 
> This change would hopefully help me, and others like me.

I agree that this would be a good change ...

> Even though there is no point in supporting "git diff A..B" (you can say
> "git diff A B" just fine), but reusing complete-revlist was the easiest
> and that form is supported as a benign but not so useful side effect.

... and this side effect is nothing to worry about, ...

> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> 
>  * I sent this out a while ago and have been using it ever since, but
>    totally forgot about it.  Likes, dislikes, alternatives?
> 
>  contrib/completion/git-completion.bash |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 64341d5..cf56514 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1137,7 +1137,7 @@ _git_diff ()
>  		return
>  		;;
>  	esac
> -	__git_complete_file
> +	__git_complete_revlist

... but I don't think this is the right solution, because it
introduces a regression.

There is this 'ref:file' notation (as in 'git show master:README', but
I don't know the proper term for it), which is understood by
__git_complete_file(), and can be useful for 'git diff', e.g. to
compare a file in two branches when the file was renamed in between:

  git diff branchA:old branchB:new

However, __git_complete_revlist() doesn't understand this notation,
and does plain filename completion after the ':', i.e. it lists all
files and dirs in the current worktree including untracked files, not
just the files that are actually present in the given ref, breaking
the completion for 'git diff branchA:o<TAB>'.

How about teaching __git_complete_file() to offer refs after '...'
instead?  It wouldn't make sense for any other commands for which we
use __git_complete_file() in the completion script, but the users
wouldn't write '...' for those commands anyway, so this is in the same
"benign but not so useful side effect" category.  But for 'git diff'
it would allow the completion of both 'git diff ...B<TAB>' and 'git
diff branch:o<TAB>'.

I mean something like this, but didn't test it that much.  The first
hunk is just a sanity check to prevent invoking 'git ls-tree' in case
the user does 'git diff ...branch:o<TAB>', because it would trigger
some error messages by 'git ls-tree', and would later cause an error
in 'git diff' anyway.


diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 893b771..2b02505 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -667,6 +667,9 @@ __git_complete_file ()
 	local pfx ls ref cur
 	_get_comp_words_by_ref -n =: cur
 	case "$cur" in
+	*...?*:*)
+		return
+		;;
 	?*:*)
 		ref="${cur%%:*}"
 		cur="${cur#*:}"
@@ -705,6 +708,11 @@ __git_complete_file ()
 				       s/^.*	//')" \
 			-- "$cur"))
 		;;
+	*...*)
+		pfx="${cur%...*}..."
+		cur="${cur#*...}"
+		__gitcomp "$(__git_refs)" "$pfx" "$cur"
+		;;
 	*)
 		__gitcomp "$(__git_refs)"
 		;;

  parent reply	other threads:[~2011-02-24 15:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-23 21:43 [PATCH] completion: complete "git diff ...branc<TAB>" Junio C Hamano
2011-02-24 12:24 ` Michael J Gruber
2011-02-24 13:58   ` SZEDER Gábor
2011-02-24 14:07     ` Michael J Gruber
2011-02-24 15:13 ` SZEDER Gábor [this message]
2011-02-24 17:09   ` Junio C Hamano
2011-03-10 18:12     ` [PATCH 1/2] bash: fix misindented esac statement in __git_complete_file() SZEDER Gábor
2011-03-10 18:12       ` [PATCH 2/2] bash: complete 'git diff ...branc<TAB>' SZEDER Gábor
2011-03-10 19:30         ` 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=20110224151328.GB14720@neumann \
    --to=szeder@ira.uka.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=spearce@spearce.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 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).