On Tue, Mar 18, 2014 at 12:00 PM, Duy Nguyen pclo...@gmail.com wrote:
size time
old aggr. 36MB 5m51
new aggr. 37MB 6m13
repack -adf 48MB 1m12
I am not clear on what these times mean. It looks like the new code is
slower _and_ bigger. Can you explain them?
That's right
On Wed, Mar 19, 2014 at 9:14 PM, Stefan Beller stefanbel...@gmail.com wrote:
Maybe we should introduce another option --pack-for-archive
which features the characteristics of the old --aggressive.
And the new --aggressive would be a tradeoff between space and
time?
Thinking further we could
On Tue, Mar 18, 2014 at 12:16 PM, Duy Nguyen pclo...@gmail.com wrote:
But I think it's orthogonal to gc --aggressive improvement.
There's another reason that improving gc may be a good idea (or not).
It depends on how other git implementations handle long delta chains.
If they hate long delta
Jeff King p...@peff.net writes:
On Tue, Mar 18, 2014 at 12:00:48PM +0700, Duy Nguyen wrote:
On Tue, Mar 18, 2014 at 11:50 AM, Jeff King p...@peff.net wrote:
On Sun, Mar 16, 2014 at 08:35:04PM +0700, Nguyễn Thái Ngọc Duy wrote:
As explained in the previous commit, current aggressive
Jeff King p...@peff.net writes:
On Tue, Mar 18, 2014 at 12:50:50AM -0400, Jeff King wrote:
On Sun, Mar 16, 2014 at 08:35:04PM +0700, Nguyễn Thái Ngọc Duy wrote:
As explained in the previous commit, current aggressive settings
--depth=250 --window=250 could slow down repository access
Duy Nguyen pclo...@gmail.com writes:
On Tue, Mar 18, 2014 at 12:16 PM, Duy Nguyen pclo...@gmail.com wrote:
But I think it's orthogonal to gc --aggressive improvement.
There's another reason that improving gc may be a good idea (or not).
It depends on how other git implementations handle long
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
As explained in the previous commit,...
[PATCH 3/4] becomes a commit with an empty log message for some
reason. Have you tried running am -s on it?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Tue, Mar 18, 2014 at 5:12 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
As explained in the previous commit,...
[PATCH 3/4] becomes a commit with an empty log message for some
reason. Have you tried running am -s on it?
am -s worked fine. am
Duy Nguyen pclo...@gmail.com writes:
On Tue, Mar 18, 2014 at 5:12 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
As explained in the previous commit,...
[PATCH 3/4] becomes a commit with an empty log message for some
reason. Have you tried
On Sun, Mar 16, 2014 at 08:35:04PM +0700, Nguyễn Thái Ngọc Duy wrote:
As explained in the previous commit, current aggressive settings
--depth=250 --window=250 could slow down repository access
significantly. Notice that people usually work on recent history only,
we could keep recent history
On Tue, Mar 18, 2014 at 11:50 AM, Jeff King p...@peff.net wrote:
On Sun, Mar 16, 2014 at 08:35:04PM +0700, Nguyễn Thái Ngọc Duy wrote:
As explained in the previous commit, current aggressive settings
--depth=250 --window=250 could slow down repository access
significantly. Notice that people
On Tue, Mar 18, 2014 at 12:50:50AM -0400, Jeff King wrote:
On Sun, Mar 16, 2014 at 08:35:04PM +0700, Nguyễn Thái Ngọc Duy wrote:
As explained in the previous commit, current aggressive settings
--depth=250 --window=250 could slow down repository access
significantly. Notice that people
On Tue, Mar 18, 2014 at 12:00:48PM +0700, Duy Nguyen wrote:
On Tue, Mar 18, 2014 at 11:50 AM, Jeff King p...@peff.net wrote:
On Sun, Mar 16, 2014 at 08:35:04PM +0700, Nguyễn Thái Ngọc Duy wrote:
As explained in the previous commit, current aggressive settings
--depth=250 --window=250
On Tue, Mar 18, 2014 at 12:07 PM, Jeff King p...@peff.net wrote:
[before]
real0m28.824s
user0m28.620s
sys 0m0.232s
[after]
real0m21.694s
user0m21.544s
sys 0m0.172s
The numbers below are completely pulled out of a hat, so we can perhaps
do even
As explained in the previous commit, current aggressive settings
--depth=250 --window=250 could slow down repository access
significantly. Notice that people usually work on recent history only,
we could keep recent history more loosely packed, so that repo access
is fast most of the time while
15 matches
Mail list logo