git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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

  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).