matches nothing). Which
> means 'foo/*/bar' cannot match 'foo/bar'. It can only match 'foo//bar'.
>
> The result of this is the current wildmatch() call works most of the
> time until the user depends on '/**/' matching no path component. And
&g
Hello,
I believe I've encountered a bug regarding the use of double asterisk
( /**/ ) within includeIf patterns.
git-config man pages state that
**/ and /**, that can match multiple path components
They then refer to the gitignore man pages which further define
supported wildcard patterns:
On Tue, Aug 15, 2017 at 1:09 PM, Igor Djordjevic
wrote:
> Hi Jason,
>
> On 15/08/2017 16:26, Jason Karns wrote:
>> I have a git repo that shows a different branch in
>> `.git/refs/remotes/origin/HEAD` than is reported by `git remote show
>> origin`.
>>
>>
fs/` but remote-show
continues to report `master` as the remote's HEAD.
Thanks,
Jason Karns
> 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.
For those curious, the source of the broken behavior is npm's
completion script. It is modifying COMP_WORDBREAKS. There are two open
issues against npm for this bug.
https://github.com/npm/npm/issues/4530
https://github.com/npm/npm/issues/5820
Jason
--
To unsubscribe from this list: send the line
On Sun, Mar 22, 2015 at 7:06 AM, SZEDER Gábor wrote:
>
> Hi,
>
> Quoting Jason Karns :
>
>> There appears to be a bug in the bash completion for git-branch when
>> attempting to complete the remote ref argument for --set-upstream-to=
>>
>> When:
>>
There appears to be a bug in the bash completion for git-branch when
attempting to complete the remote ref argument for --set-upstream-to=
When:
$ git branch --set-upstream-to=origin/mast
I would expect it to complete to:
$ git branch --set-upstream-to=origin/master
However, the completion for
8 matches
Mail list logo
