All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] completion: complete "git diff ...branc<TAB>"
@ 2011-02-23 21:43 Junio C Hamano
  2011-02-24 12:24 ` Michael J Gruber
  2011-02-24 15:13 ` SZEDER Gábor
  0 siblings, 2 replies; 9+ messages in thread
From: Junio C Hamano @ 2011-02-23 21:43 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: git, Jonathan Nieder

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.

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.

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
 }
 
 __git_mergetools_common="diffuse ecmerge emerge kdiff3 meld opendiff

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] completion: complete "git diff ...branc<TAB>"
  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 15:13 ` SZEDER Gábor
  1 sibling, 1 reply; 9+ messages in thread
From: Michael J Gruber @ 2011-02-24 12:24 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Jonathan Nieder

Junio C Hamano venit, vidit, dixit 23.02.2011 22:43:
> 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.
> 
> 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.
> 
> 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?

Likes

Reminds me fo the following: Typing

git log origin/next@{1}..o<TAB>

gives

git log origin/next{1}..o

WTF? Completion eats at babies!

Michael

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] completion: complete "git diff ...branc<TAB>"
  2011-02-24 12:24 ` Michael J Gruber
@ 2011-02-24 13:58   ` SZEDER Gábor
  2011-02-24 14:07     ` Michael J Gruber
  0 siblings, 1 reply; 9+ messages in thread
From: SZEDER Gábor @ 2011-02-24 13:58 UTC (permalink / raw)
  To: Michael J Gruber; +Cc: Junio C Hamano, Shawn O. Pearce, git, Jonathan Nieder

On Thu, Feb 24, 2011 at 01:24:57PM +0100, Michael J Gruber wrote:
> Reminds me fo the following: Typing
> 
> git log origin/next@{1}..o<TAB>
> 
> gives
> 
> git log origin/next{1}..o
> 
> WTF? Completion eats at babies!

Interesting, I can't seem to be able to reproduce.

  git log origin/next@{1}..o<TAB>

gives me

  git log origin/next@{1}..origin/

and a TAB after that gives me all the remote branches from origin, as
it is supposed to, leaving the @{1} intact.

Which git, bash, and bash completion versions are you using?


Best,
Gábor

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] completion: complete "git diff ...branc<TAB>"
  2011-02-24 13:58   ` SZEDER Gábor
@ 2011-02-24 14:07     ` Michael J Gruber
  0 siblings, 0 replies; 9+ messages in thread
From: Michael J Gruber @ 2011-02-24 14:07 UTC (permalink / raw)
  To: SZEDER Gábor; +Cc: Junio C Hamano, Shawn O. Pearce, git, Jonathan Nieder

SZEDER Gábor venit, vidit, dixit 24.02.2011 14:58:
> On Thu, Feb 24, 2011 at 01:24:57PM +0100, Michael J Gruber wrote:
>> Reminds me fo the following: Typing
>>
>> git log origin/next@{1}..o<TAB>
>>
>> gives
>>
>> git log origin/next{1}..o
>>
>> WTF? Completion eats at babies!
> 
> Interesting, I can't seem to be able to reproduce.
> 
>   git log origin/next@{1}..o<TAB>
> 
> gives me
> 
>   git log origin/next@{1}..origin/
> 
> and a TAB after that gives me all the remote branches from origin, as
> it is supposed to, leaving the @{1} intact.
> 
> Which git, bash, and bash completion versions are you using?

git version 1.7.4.1.224.gefc87
(yesterday's next, but I've been observing this for a while now)

GNU bash, Version 4.1.7(1)-release (x86_64-redhat-linux-gnu)
(Fedora 14+updates)

git-completion from next a few days ago

(Also, I just tried with LANG=C, so it's not the de_DE locale nor utf8.)

Michael

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] completion: complete "git diff ...branc<TAB>"
  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 15:13 ` SZEDER Gábor
  2011-02-24 17:09   ` Junio C Hamano
  1 sibling, 1 reply; 9+ messages in thread
From: SZEDER Gábor @ 2011-02-24 15:13 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Jonathan Nieder

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)"
 		;;

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] completion: complete "git diff ...branc<TAB>"
  2011-02-24 15:13 ` SZEDER Gábor
@ 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
  0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2011-02-24 17:09 UTC (permalink / raw)
  To: SZEDER Gábor; +Cc: Shawn O. Pearce, git, Jonathan Nieder

SZEDER Gábor <szeder@ira.uka.de> writes:

> 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,

If that is the case, I wonder if complete-revlist should learn it as well.
The "<tree>:<path>" notation is just one of the "extended SHA-1
expressions" to name an entry in a tree object and should be usable
anywhere an object name is expected to occur.

The users of complete-revlist seems to be "log" and their friends, and
they don't expect arbitrary object names; they are only interested in
commit objects and tags and then paths.  Teaching <tree>:<path> to it may
make "git log HEAD:bar<TAB>" to complete to "git log HEAD:bar/boz" that
would be a nonsense, but anything that the original "git log HEAD:bar"
would complete would be a nonsense to begin with (as soon as you said
"HEAD:<something to follow>", you are naming either a blob or a tree
object, and you cannot start log from them), so I don't see a harm done in
doing so.

IOW, shouldn't there be just one unified complete-rev-then-path that is a
superset of the current complete-revlist and complete-file that all the
current users of complete-revlist and complete-file should use?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH 1/2] bash: fix misindented esac statement in __git_complete_file()
  2011-02-24 17:09   ` Junio C Hamano
@ 2011-03-10 18:12     ` SZEDER Gábor
  2011-03-10 18:12       ` [PATCH 2/2] bash: complete 'git diff ...branc<TAB>' SZEDER Gábor
  0 siblings, 1 reply; 9+ messages in thread
From: SZEDER Gábor @ 2011-03-10 18:12 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Jonathan Nieder, SZEDER Gábor

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
 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 893b771..344a47f 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -680,7 +680,7 @@ __git_complete_file ()
 		*)
 			ls="$ref"
 			;;
-	    esac
+		esac
 
 		case "$COMP_WORDBREAKS" in
 		*:*) : great ;;
-- 
1.7.4.1.237.g62e25

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH 2/2] bash: complete 'git diff ...branc<TAB>'
  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       ` SZEDER Gábor
  2011-03-10 19:30         ` Junio C Hamano
  0 siblings, 1 reply; 9+ messages in thread
From: SZEDER Gábor @ 2011-03-10 18:12 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Jonathan Nieder, SZEDER Gábor

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

Unfortunately, our completion script for 'git diff' doesn't offer
anything after '...'.  This is because 'git diff's completion function
invokes __git_complete_file() for non-option arguments to complete the
'<tree>:<path>' extended SHA-1 notation, but this helper function
doesn't support refs after '...' or '..'.  Completion of refs after
'...' or '..' is supported by the __git_complete_revlist() helper
function, but that doesn't support '<tree>:<path>'.

To support both '...<ref>' and '<tree>:<path>' notations for 'git
diff', this patch, instead of adding yet another helper function,
joins __git_complete_file() and __git_complete_revlist() into the new
common function __git_complete_revlist_file().  The old helper
functions __git_complete_file() and __git_complete_revlist() are
changed to be a direct wrapper around the new
__git_complete_revlist_file(), because they might be used in
user-supplied completion scripts and we don't want to break them.

This change will cause some wrong suggestions for other commands which
use __git_complete_file() ('git diff' and friends) or
__git_complete_revlist() ('git log' and friends), e.g. 'git diff
...master:Doc<TAB>' and 'git log master:Doc<TAB>' will complete the
path to 'Documentation/', although neither commands make any sense.
However, both of these were actively wrong to begin with as soon as
the user entered the ':', so there is no real harm done.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
 contrib/completion/git-completion.bash |   29 ++++++++++++++++-------------
 1 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 344a47f..0c48f1a 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -662,11 +662,14 @@ __git_compute_merge_strategies ()
 	: ${__git_merge_strategies:=$(__git_list_merge_strategies)}
 }
 
-__git_complete_file ()
+__git_complete_revlist_file ()
 {
 	local pfx ls ref cur
 	_get_comp_words_by_ref -n =: cur
 	case "$cur" in
+	*..?*:*)
+		return
+		;;
 	?*:*)
 		ref="${cur%%:*}"
 		cur="${cur#*:}"
@@ -705,17 +708,6 @@ __git_complete_file ()
 				       s/^.*	//')" \
 			-- "$cur"))
 		;;
-	*)
-		__gitcomp "$(__git_refs)"
-		;;
-	esac
-}
-
-__git_complete_revlist ()
-{
-	local pfx cur
-	_get_comp_words_by_ref -n =: cur
-	case "$cur" in
 	*...*)
 		pfx="${cur%...*}..."
 		cur="${cur#*...}"
@@ -732,6 +724,17 @@ __git_complete_revlist ()
 	esac
 }
 
+
+__git_complete_file ()
+{
+	__git_complete_revlist_file
+}
+
+__git_complete_revlist ()
+{
+	__git_complete_revlist_file
+}
+
 __git_complete_remote_or_refspec ()
 {
 	local cur words cword
@@ -1354,7 +1357,7 @@ _git_diff ()
 		return
 		;;
 	esac
-	__git_complete_file
+	__git_complete_revlist_file
 }
 
 __git_mergetools_common="diffuse ecmerge emerge kdiff3 meld opendiff
-- 
1.7.4.1.237.g62e25

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH 2/2] bash: complete 'git diff ...branc<TAB>'
  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
  0 siblings, 0 replies; 9+ messages in thread
From: Junio C Hamano @ 2011-03-10 19:30 UTC (permalink / raw)
  To: SZEDER Gábor; +Cc: Shawn O. Pearce, git, Jonathan Nieder

Thanks.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2011-03-10 19:31 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

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.