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 <redacted>
---
* 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
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 <redacted>
---
* 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
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
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:
quoted
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
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, ...
quoted hunk
Signed-off-by: Junio C Hamano <redacted>
---
* 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)"
;;