On Wed, Feb 24, 2016 at 12:30 AM, Junio C Hamano wrote:
> So, have we decided to wait, or we'd rather apply the band-aid in
> the meantime? I can go either way, just double checking as I
> noticed this thread while updating my leftover bits list.
Thanks for the follow-up, I was about to ask for
Junio C Hamano writes:
> Jeff King writes:
>
>> On Fri, Feb 12, 2016 at 10:40:48PM +0100, SZEDER Gábor wrote:
>>
>>> * It would swallow even those errors that we are interested in,
>>>e.g. (note the missing quotes around $foo):
>>> [...]
>>> * I often find myself tracing/debugging the comp
Hi Gábor,
On Sat, 13 Feb 2016, SZEDER Gábor wrote:
> Maybe even run some numbers on Windows?
Here you are:
-- snip --
# Junio's 494398473, i.e. `master
$ cur=m ; time __gitcomp_nl "$(__git_refs '' 1)"
real0m8.260s
user0m0.265s
sys 0m0.216s
# Gábor's 6fc6f416, i.e. with strip=2
$ c
On Sat, Feb 13, 2016 at 02:07:12AM +0100, SZEDER Gábor wrote:
> >So I think switching to :strip is an improvement in both correctness
> >_and_ performance.
>
> Right. I was more worried about __git_refs(), because it asks for
> everything under refs/heads/, refs/tags/ and refs/remotes/, and its
Quoting Johannes Schindelin :
Hi Gábor,
On Sat, 13 Feb 2016, SZEDER Gábor wrote:
$ cur=m ; time __gitcomp_nl "$(__git_refs '' 1)"
real 0m7.641s
user 0m5.888s
sys 0m1.832s
Using 'refname:strip=2' for both 'git for-each-ref' in __git_refs():
$ cur=m ; time __gitcomp_nl "$(__git_ref
Hi Gábor,
On Sat, 13 Feb 2016, SZEDER Gábor wrote:
> $ cur=m ; time __gitcomp_nl "$(__git_refs '' 1)"
>
> real 0m7.641s
> user 0m5.888s
> sys 0m1.832s
>
> Using 'refname:strip=2' for both 'git for-each-ref' in __git_refs():
>
> $ cur=m ; time __gitcomp_nl "$(__git_refs '' 1)"
>
> re
Quoting Jeff King :
On Sat, Feb 13, 2016 at 12:21:22AM +0100, SZEDER Gábor wrote:
I think in this case we should opt for performance instead of correctness,
and use Peff's 'refname:strip=2'. Ambiguous refs will only hurt you, if,
well, your repo actually has ambiguous refs AND you happen to
On Sat, Feb 13, 2016 at 6:46 AM, Jeff King wrote:
> On Sat, Feb 13, 2016 at 12:43:00AM +0100, SZEDER Gábor wrote:
>
>>
>> Quoting SZEDER Gábor :
>>
>> >Now, if 'git for-each-ref' could understand '**' globbing, not just
>> >fnmatch...
>>
>> Oh, look, though the manpage says:
>>
>> ...
>> I
On Sat, Feb 13, 2016 at 12:43:00AM +0100, SZEDER Gábor wrote:
>
> Quoting SZEDER Gábor :
>
> >Now, if 'git for-each-ref' could understand '**' globbing, not just
> >fnmatch...
>
> Oh, look, though the manpage says:
>
> ...
> If one or more patterns are given, only refs are shown that m
Quoting SZEDER Gábor :
Now, if 'git for-each-ref' could understand '**' globbing, not just
fnmatch...
Oh, look, though the manpage says:
...
If one or more patterns are given, only refs are shown that match
against at least one pattern, either using fnmatch(3) or literally,
'g
On Sat, Feb 13, 2016 at 12:21:22AM +0100, SZEDER Gábor wrote:
> I think in this case we should opt for performance instead of correctness,
> and use Peff's 'refname:strip=2'. Ambiguous refs will only hurt you, if,
> well, your repo actually has ambiguous refs AND you happen to want to do
> someth
Jeff King writes:
> On Fri, Feb 12, 2016 at 10:40:48PM +0100, SZEDER Gábor wrote:
>
>> * It would swallow even those errors that we are interested in,
>>e.g. (note the missing quotes around $foo):
>> [...]
>> * I often find myself tracing/debugging the completion script
>>through stderr
Quoting Johannes Schindelin :
Hi Peff,
On Thu, 4 Feb 2016, Jeff King wrote:
> diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
> index 15ebba5..7c0549d 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completi
On Fri, Feb 12, 2016 at 10:40:48PM +0100, SZEDER Gábor wrote:
> * It would swallow even those errors that we are interested in,
>e.g. (note the missing quotes around $foo):
> [...]
> * I often find myself tracing/debugging the completion script
>through stderr by scattering
>
> ec
Quoting Junio C Hamano :
Jeff King writes:
On Thu, Feb 04, 2016 at 11:34:59AM +0100, Sebastian Schuberth wrote:
This avoids output like
warning: ignoring broken ref refs/remotes/origin/HEAD
while completing branch names.
Hmm. I feel like this case (HEAD points to a branch, then `fe
Jeff King writes:
> I agree it's a lot more pleasant, assuming there are no cases where we
> would want to pass through an error. But I really cannot think of one.
> Even explosive "woah, your git repo is totally corrupted" messages
> probably should be suppressed in the prompt.
>
>> @@ -320,7 +3
On Fri, Feb 12, 2016 at 12:00:43PM -0800, Junio C Hamano wrote:
> > Anyway, I this is a reasonable workaround. Errors from bash completion
> > scripts are almost always going to be useless and get in the way of
> > reading your own prompt.
>
> I think that is absolutely the right stance to take,
Jeff King writes:
> On Thu, Feb 04, 2016 at 11:34:59AM +0100, Sebastian Schuberth wrote:
>
>> This avoids output like
>>
>> warning: ignoring broken ref refs/remotes/origin/HEAD
>>
>> while completing branch names.
>
> Hmm. I feel like this case (HEAD points to a branch, then `fetch
> --pru
On 04.02.2016 11:34, Sebastian Schuberth wrote:
This avoids output like
warning: ignoring broken ref refs/remotes/origin/HEAD
while completing branch names.
Signed-off-by: Sebastian Schuberth
The discussion got a bit off the point with the "short" vs. "strip=2"
stuff, but I guess the
Johannes Schindelin writes:
>> $ time git for-each-ref --format='%(refname:short)' refs/tags >/dev/null
>>
>> real0m0.009s
>> user0m0.004s
>> sys 0m0.004s
>
> And the timings in the ticket I mentioned above are not pretty small:
> 0.055s vs 1.341s
>
>> The upcoming refname:strip does
On Thu, Feb 04, 2016 at 12:26:19PM +0100, Johannes Schindelin wrote:
> > Hmm. I feel like this case (HEAD points to a branch, then `fetch
> > --prune` deletes it) came up recently and we discussed quieting that
> > warning. But now I cannot seem to find it.
>
> I am pretty certain that it came up
Hi Peff,
On Thu, 4 Feb 2016, Jeff King wrote:
> On Thu, Feb 04, 2016 at 11:34:59AM +0100, Sebastian Schuberth wrote:
>
> > This avoids output like
> >
> > warning: ignoring broken ref refs/remotes/origin/HEAD
> >
> > while completing branch names.
>
> Hmm. I feel like this case (HEAD poin
On Thu, Feb 04, 2016 at 11:34:59AM +0100, Sebastian Schuberth wrote:
> This avoids output like
>
> warning: ignoring broken ref refs/remotes/origin/HEAD
>
> while completing branch names.
Hmm. I feel like this case (HEAD points to a branch, then `fetch
--prune` deletes it) came up recently
This avoids output like
warning: ignoring broken ref refs/remotes/origin/HEAD
while completing branch names.
Signed-off-by: Sebastian Schuberth
---
contrib/completion/git-completion.bash | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/contrib/completion/git-c
24 matches
Mail list logo
