From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] completion: optionally disable checkout DWIM
Date: Fri, 21 Apr 2017 22:14:48 +0200 [thread overview]
Message-ID: <CAM0VKjm=JMuYzsS-OTx+p-vFF8PmWJGbFnndag9dWw6xCe3g6Q@mail.gmail.com> (raw)
In-Reply-To: <xmqqzifa4amr.fsf@gitster.mtv.corp.google.com>
On Fri, Apr 21, 2017 at 7:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> When we complete branch names for "git checkout", we also
>> complete remote branch names that could trigger the DWIM
>> behavior. Depending on your workflow and project, this can
>> be either convenient or annoying.
>> ...
>> This is flexible enough for me, but it's possible somebody would want
>> this on a per-repo basis. I don't know that we want to read from `git
>> config`, though, because it's relatively expensive to do so. People who
>> want per-repo settings are probably better off with a hook that triggers
>> when they "cd" around, and sets up their preferences.
We could discern between more than just empty vs. non-empty state of
the environment variable, e.g.:
- if empty/unset, then include "DWIM" suggestions.
- if set to 'config', then query the 'completion.checkoutNoGuess'
configuration variable, and omit "DWIM" suggestions if its true.
- if set to something else, then omit "DWIM" suggestions.
Then users can themselves decide, whether the per-repo configurability
is worth the overhead of running 'git config'.
> Sounds OK. I am kind of surprised that --no-guess is the only way
> to turn off this dwimming (not in the completion side, but there
> does not seem to be a way to tell "git checkout" that you do not
> need that create-missing-branch-out-of-remote-tracking).
>
>> contrib/completion/git-completion.bash | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index 1150164d5..f53b18fae 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -28,6 +28,14 @@
>> # completion style. For example '!f() { : git commit ; ... }; f' will
>> # tell the completion to use commit completion. This also works with aliases
>> # of form "!sh -c '...'". For example, "!sh -c ': git commit ; ... '".
>> +#
>> +# You can set the following environment variables to influence the behavior of
>> +# the completion routines:
>> +#
>> +# GIT_COMPLETION_CHECKOUT_NO_GUESS
That's one long variable name :)
Of course it has to start with the 'GIT_COMPLETION_' prefix, and you
can't win from there...
>> +# When non-empty, do not include "DWIM" suggestions in git-checkout
>> +# completion (e.g., completing "foo" when "origin/foo" exists).
>>
>> case "$COMP_WORDBREAKS" in
>> *:*) : great ;;
>> @@ -1248,7 +1256,8 @@ _git_checkout ()
>> # check if --track, --no-track, or --no-guess was specified
>> # if so, disable DWIM mode
>> local flags="--track --no-track --no-guess" track_opt="--track"
>> - if [ -n "$(__git_find_on_cmdline "$flags")" ]; then
>> + if [ -n "$GIT_COMPLETION_CHECKOUT_NO_GUESS" -o \
>> + -n "$(__git_find_on_cmdline "$flags")" ]; then
|| would be better than '-o', because the former short-circuits when
the first condition is true, but the latter doesn't.
>> track_opt=''
>> fi
>> __git_complete_refs $track_opt
On Fri, Apr 21, 2017 at 7:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> When we complete branch names for "git checkout", we also
>> complete remote branch names that could trigger the DWIM
>> behavior. Depending on your workflow and project, this can
>> be either convenient or annoying.
>> ...
>> This is flexible enough for me, but it's possible somebody would want
>> this on a per-repo basis. I don't know that we want to read from `git
>> config`, though, because it's relatively expensive to do so. People who
>> want per-repo settings are probably better off with a hook that triggers
>> when they "cd" around, and sets up their preferences.
>
> Sounds OK. I am kind of surprised that --no-guess is the only way
> to turn off this dwimming (not in the completion side, but there
> does not seem to be a way to tell "git checkout" that you do not
> need that create-missing-branch-out-of-remote-tracking).
>
>> contrib/completion/git-completion.bash | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index 1150164d5..f53b18fae 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -28,6 +28,14 @@
>> # completion style. For example '!f() { : git commit ; ... }; f' will
>> # tell the completion to use commit completion. This also works with aliases
>> # of form "!sh -c '...'". For example, "!sh -c ': git commit ; ... '".
>> +#
>> +# You can set the following environment variables to influence the behavior of
>> +# the completion routines:
>> +#
>> +# GIT_COMPLETION_CHECKOUT_NO_GUESS
>> +#
>> +# When non-empty, do not include "DWIM" suggestions in git-checkout
>> +# completion (e.g., completing "foo" when "origin/foo" exists).
>>
>> case "$COMP_WORDBREAKS" in
>> *:*) : great ;;
>> @@ -1248,7 +1256,8 @@ _git_checkout ()
>> # check if --track, --no-track, or --no-guess was specified
>> # if so, disable DWIM mode
>> local flags="--track --no-track --no-guess" track_opt="--track"
>> - if [ -n "$(__git_find_on_cmdline "$flags")" ]; then
>> + if [ -n "$GIT_COMPLETION_CHECKOUT_NO_GUESS" -o \
>> + -n "$(__git_find_on_cmdline "$flags")" ]; then
>> track_opt=''
>> fi
>> __git_complete_refs $track_opt
next prev parent reply other threads:[~2017-04-21 20:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 20:12 [PATCH] completion: optionally disable checkout DWIM Jeff King
2017-04-21 5:01 ` Junio C Hamano
2017-04-21 5:03 ` Jeff King
2017-04-21 5:30 ` Junio C Hamano
2017-04-21 20:14 ` SZEDER Gábor [this message]
2017-04-21 20:19 ` Jeff King
2017-04-22 17:32 ` SZEDER Gábor
2017-04-21 7:25 ` Jacob Keller
2017-04-21 20:27 ` [PATCH v2] " Jeff King
2017-04-24 16:30 ` Brandon Williams
-- strict thread matches above, loose matches on Subject: below --
2017-06-29 20:03 [PATCH] " Jason Karns
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAM0VKjm=JMuYzsS-OTx+p-vFF8PmWJGbFnndag9dWw6xCe3g6Q@mail.gmail.com' \
--to=szeder.dev@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).