On 18.01.13 01:04, Jonathan Nieder wrote:
> Jean-Noël AVILA wrote:
>
>> OK. I have installed practically everything related to git from the package
>> manager and there is a git-checkout-branches utility available.
>>
>> That result defeats the purpose of the test. This needs a tighter
>> environ
Jean-Noël AVILA wrote:
> OK. I have installed practically everything related to git from the package
> manager and there is a git-checkout-branches utility available.
>
> That result defeats the purpose of the test. This needs a tighter environment
> to work whatever the configuration of the use
Le mercredi 16 janvier 2013 07:15:51, Torsten Bögershausen a écrit :
> On 01/16/2013 12:24 AM, Jeff King wrote:
> > On Tue, Jan 15, 2013 at 12:49:05PM -0800, Junio C Hamano wrote:
> >> "Jean-Noël AVILA" writes:
> >>> Btw, the test 10 to t9902 is failing on my Debian testing. Is it a
> >>> known is
Duy Nguyen writes:
> OK I get your point now. Something like this?
>
> -- 8< --
> Subject: [PATCH] attr: avoid calling find_basename() twice per path
>
> find_basename() is only used inside collect_all_attrs(), called once
> in prepare_attr_stack, then again after prepare_attr_stack()
> returns.
On 01/16/2013 12:24 AM, Jeff King wrote:
On Tue, Jan 15, 2013 at 12:49:05PM -0800, Junio C Hamano wrote:
"Jean-Noël AVILA" writes:
Btw, the test 10 to t9902 is failing on my Debian testing. Is it a known
issue?
Which branch?
t9902.10 is overly sensitive to extra git commands in your PATH
On Tue, Jan 15, 2013 at 09:35:21PM -0800, Junio C Hamano wrote:
> >> Also the original only
> >> scanned the string from the beginning once (instead of letting
> >> strlen() to scan once and go back).
> >
> > But we do need to strlen() anyway in collect_all_attrs().
>
> That is exactly my point, i
Duy Nguyen writes:
> On Wed, Jan 16, 2013 at 9:33 AM, Junio C Hamano wrote:
>> Duy Nguyen writes:
>>
>>> On Wed, Jan 16, 2013 at 08:08:03AM +0700, Duy Nguyen wrote:
Actually I'd like to remove that function.
>>>
>>> This is what I had in mind:
>>
>> I think the replacement logic to find th
On Wed, Jan 16, 2013 at 9:33 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Wed, Jan 16, 2013 at 08:08:03AM +0700, Duy Nguyen wrote:
>>> Actually I'd like to remove that function.
>>
>> This is what I had in mind:
>
> I think the replacement logic to find the basename is moderately
> infe
Duy Nguyen writes:
> On Wed, Jan 16, 2013 at 08:08:03AM +0700, Duy Nguyen wrote:
>> Actually I'd like to remove that function.
>
> This is what I had in mind:
I think the replacement logic to find the basename is moderately
inferiour to the original. For one thing (this may be somewhat
subjecti
On Wed, Jan 16, 2013 at 08:08:03AM +0700, Duy Nguyen wrote:
> Actually I'd like to remove that function.
This is what I had in mind:
-- 8< --
Subject: [PATCH] attr: avoid calling find_basename() twice per path
find_basename() is only used inside collect_all_attrs(), called once
in prepare_attr_s
On Wed, Jan 16, 2013 at 2:29 AM, Junio C Hamano wrote:
> "Jean-Noël AVILA" writes:
>
>> Thank you for the explanation.
>>
>> I did not monitor the system calls when writing that patch.
>> Where is the perf framework?
>>
>> As the mistake is located in the "find_basename" function, I would propose
On Wed, Jan 16, 2013 at 2:14 AM, Jean-Noël AVILA wrote:
> I did not monitor the system calls when writing that patch.
> Where is the perf framework?
It's in t/perf. I think you can do:
./run HEAD .
to run and compare performance of HEAD and working directory (assume
you haven't commit yet). Che
On Tue, Jan 15, 2013 at 12:49:05PM -0800, Junio C Hamano wrote:
> "Jean-Noël AVILA" writes:
>
> > Btw, the test 10 to t9902 is failing on my Debian testing. Is it a known
> > issue?
>
> Which branch?
t9902.10 is overly sensitive to extra git commands in your PATH, as well
as cruft in your bui
"Jean-Noël AVILA" writes:
> Btw, the test 10 to t9902 is failing on my Debian testing. Is it a known
> issue?
Which branch?
If you mean "'master' with the patch in this discussion applied", I
didn't even have a chance to start today's integration cycle, so I
don't know (it is not known to me).
Le mardi 15 janvier 2013 20:29:16, Junio C Hamano a écrit :
> "Jean-Noël AVILA" writes:
> > Thank you for the explanation.
> >
> > I did not monitor the system calls when writing that patch.
> > Where is the perf framework?
> >
> > As the mistake is located in the "find_basename" function, I wou
"Jean-Noël AVILA" writes:
> Thank you for the explanation.
>
> I did not monitor the system calls when writing that patch.
> Where is the perf framework?
>
> As the mistake is located in the "find_basename" function, I would propose a
> fix directly into it so that the output fits what the othe
Thank you for the explanation.
I did not monitor the system calls when writing that patch.
Where is the perf framework?
As the mistake is located in the "find_basename" function, I would propose a
fix directly into it so that the output fits what the other functions expect.
Something in the li
Good spotting and a nicely explained patch. Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
94bc671 (Add directory pattern matching to attributes - 2012-12-08)
uses find_basename() to calculate the length of directory part in
prepare_attr_stack. This function expects the directory without the
trailing slash (as "origin" field in match_attr struct is without the
trailing slash). find_basen
19 matches
Mail list logo
