On Fri, Oct 05, 2012 at 10:20:37PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> > @@ -617,6 +618,8 @@ static struct commit_list
> >> > *paint_down_to_common(struct commit *one, int n, struc
> >> >
> >> > one->object.flags |= PARENT1;
> >> > commit_list_insert_by_d
Jeff King writes:
>> > @@ -617,6 +618,8 @@ static struct commit_list *paint_down_to_common(struct
>> > commit *one, int n, struc
>> >
>> >one->object.flags |= PARENT1;
>> >commit_list_insert_by_date(one, &list);
>> > + if (!n)
>> > + return list;
>> >for (i = 0; i < n; i+
On Fri, Oct 05, 2012 at 01:34:02PM -0700, Junio C Hamano wrote:
> OK, I think I am convinced myself that this patch is the right fix.
>
> The performance regression Markus saw is in fmt-merge-message, and
> it is caused by the updated remove_redundant() that is used by
> get_merge_bases_many() an
Junio C Hamano writes:
> Here is a tested (in the sense that it passes the test suite, and
> also in the sense that an empty pull in the kernel history gives
> quick turnaround) patch. As I do not think we would want to revert
> 5802f81 (fmt-merge-msg: discard needless merge parents, 2012-04-18)
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Jeff King writes:
>>
>>> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>>>
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
>>>
Junio C Hamano writes:
> Jeff King writes:
>
>> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>>
>>> with current trunk I get the following on an up-to-date Linux tree:
>>>
>>> markus@x4 linux % time git pull
>>> Already up-to-date.
>>> git pull 7.84s user 0.26s system 9
Jeff King writes:
> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>
>> with current trunk I get the following on an up-to-date Linux tree:
>>
>> markus@x4 linux % time git pull
>> Already up-to-date.
>> git pull 7.84s user 0.26s system 92% cpu 8.743 total
>>
>> git versi
Junio C Hamano writes:
> It gets more curious, though.
> ...
> However.
>
> If I revert 5802f81 that updated the implementation of fmt-merge-msg
> on top of 'master', *without* reverting 34f5130^2, I get ~4.5 seconds.
> As we are doing an "Already up-to-date" pull, I thought there is no
> need to
Jeff King writes:
> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>
>> with current trunk I get the following on an up-to-date Linux tree:
>>
>> markus@x4 linux % time git pull
>> Already up-to-date.
>> git pull 7.84s user 0.26s system 92% cpu 8.743 total
>>
>> git versi
Jeff King writes:
> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>
>> with current trunk I get the following on an up-to-date Linux tree:
>>
>> markus@x4 linux % time git pull
>> Already up-to-date.
>> git pull 7.84s user 0.26s system 92% cpu 8.743 total
>>
>> git versi
On 2012.10.04 at 14:43 -0400, Jeff King wrote:
> On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
>
> > with current trunk I get the following on an up-to-date Linux tree:
> >
> > markus@x4 linux % time git pull
> > Already up-to-date.
> > git pull 7.84s user 0.26s system 92%
On Thu, Oct 04, 2012 at 04:14:54PM +0200, Markus Trippelsdorf wrote:
> with current trunk I get the following on an up-to-date Linux tree:
>
> markus@x4 linux % time git pull
> Already up-to-date.
> git pull 7.84s user 0.26s system 92% cpu 8.743 total
>
> git version 1.7.12 is much quicker:
>
Hi,
with current trunk I get the following on an up-to-date Linux tree:
markus@x4 linux % time git pull
Already up-to-date.
git pull 7.84s user 0.26s system 92% cpu 8.743 total
git version 1.7.12 is much quicker:
markus@x4 linux % time git pull
Already up-to-date.
git pull 0.10s user 0.02s sy
13 matches
Mail list logo
