All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Petr Baudis <pasky@suse.cz>
Cc: "Shawn O. Pearce" <spearce@spearce.org>, git@vger.kernel.org
Subject: Re: [PATCH] bash completion: Fix the . -> .. revision range completion
Date: Sun, 13 Jul 2008 14:38:37 -0700	[thread overview]
Message-ID: <7vskudpiqq.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 20080713111847.29801.8969.stgit@localhost

Petr Baudis <pasky@suse.cz> writes:

> When Git sees a string with trailing dot on a place where revision
> range could occur, it will unconditionally append another dot to
> it to help complete a revision range. However, filespec can usually
> occur at such a place as well. I have been hitting this all the time
> lately with
>
> 	git log git-submodule.<tab>
>
> and the like.

Modulo s/Git/bash-completion/ ;-) I think this makes sense.

> This patch will make Git perform the . -> .. completion in
> __git_complete_revlist only if there is no filename starting with
> the entered prefix available.  At few places, filename could not occur
> when calling __git_complete_revlist; however, taking this into account
> did not seem worth complicating the code further.

Theoretically we could take a hint from presense of '--' like d773c63
(bash: offer only paths after '--', 2008-07-08) did.  If the command line
has double-dash and the token we are looking at is before it, it cannot be
pathname and this check does not have to trigger.  But I agree that is not
worth it, because this "theoretical" solution would mean that the user
needs to something awkward like:

	git log v1.5.6. --<C-b><C-b><C-b><TAB>

to take advantage of it.

By the way, the above command line is another "dot" related frustration I
always have.  If you try:

	git log v1.5.6.<TAB>

the completion code adds a dot unconditionally when I want to choose from
the list of v1.5.6.X tags.  Of course, I can work this around by dropping
the last dot before asking for completion, so it is not really a very big
deal, but I mention it here because this annoyance is exactly in the same
league as your "git-submodule.<TAB>" example.

"git show v1.5.6.<TAB>" does complete as expected, which is understandable
(the command does not take range, and completion knows about it -- which
is quite nice).

>  contrib/completion/git-completion.bash |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 61581fe..fe24b8c 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -325,7 +325,12 @@ __git_complete_revlist ()
>  		__gitcomp "$(__git_refs)" "$pfx" "$cur"
>  		;;
>  	*.)
> -		__gitcomp "$cur."
> +		if ls "$cur"* >/dev/null 2>&1; then

There is a slight Yuck factor for using "ls" here but I do not think of a
better alternative offhand.

Will queue on top of Shawn's previous one.  Thanks.

  parent reply	other threads:[~2008-07-13 21:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-13 11:19 [PATCH] bash completion: Fix the . -> .. revision range completion Petr Baudis
2008-07-13 12:11 ` Jakub Narebski
2008-07-13 21:38 ` Junio C Hamano [this message]
2008-07-13 22:06   ` Shawn O. Pearce
2008-07-13 23:07   ` Petr Baudis
2008-07-13 23:25     ` Junio C Hamano
2008-07-13 23:52       ` Linus Torvalds
2008-07-14  0:00         ` Shawn O. Pearce
2008-07-14  5:38           ` Linus Torvalds
2008-07-14  5:57             ` Shawn O. Pearce
2008-07-14  6:27             ` Shawn O. Pearce
2008-07-14  6:47               ` Björn Steinbrink
2008-07-14  6:50                 ` Björn Steinbrink
2008-07-14 12:39                   ` Andreas Ericsson
2008-07-14 14:51                   ` Linus Torvalds
2008-07-14 14:50               ` Linus Torvalds
2008-07-15  4:25                 ` Shawn O. Pearce
2008-07-15  8:05                   ` Andreas Ericsson
2008-07-15  8:10                     ` Andreas Ericsson
2008-07-15  8:17                       ` Andreas Ericsson
2008-07-15 23:38                     ` Shawn O. Pearce
2008-07-16  7:20                       ` Andreas Ericsson

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=7vskudpiqq.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    --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 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.