> I used to repack older part of history manually with a deeper depth,
> mark the result with the .keep bit, and then repack the whole thing
> again to have the remainder in a shallower depth. Something like:
>
> git rev-list --objects v1.5.3 |
> git pack-objects --depth=128 --delt
On Sat, Feb 22, 2014 at 4:14 PM, Duy Nguyen wrote:
> On Sat, Feb 22, 2014 at 3:53 PM, David Kastrup wrote:
>> David Kastrup writes:
>>
>>> Duy Nguyen writes:
>>>
OK with git://git.savannah.gnu.org/emacs.git we have
- a 209MB pack with --aggressive
- 1.3GB with --depth=50
>
David Kastrup writes:
> That does look strange: Emacs has a history of more than 30 years. But
> the Git mirror is quite younger. Maybe one needs to make sure to use
> the author date rather than the commit date here?
There is no difference between commit and author date in the Emacs git
mirro
On Sat, Feb 22, 2014 at 3:53 PM, David Kastrup wrote:
> David Kastrup writes:
>
>> Duy Nguyen writes:
>>
>>> OK with git://git.savannah.gnu.org/emacs.git we have
>>>
>>> - a 209MB pack with --aggressive
>>> - 1.3GB with --depth=50
>>> - 1.3GB with --window=4000 --depth=32
>>> - 1.3GB with --
David Kastrup writes:
> Duy Nguyen writes:
>
>> OK with git://git.savannah.gnu.org/emacs.git we have
>>
>> - a 209MB pack with --aggressive
>> - 1.3GB with --depth=50
>> - 1.3GB with --window=4000 --depth=32
>> - 1.3GB with --depth=20
>> - 821MB with --depth=250 for commits --before=2.years
Duy Nguyen writes:
> OK with git://git.savannah.gnu.org/emacs.git we have
>
> - a 209MB pack with --aggressive
> - 1.3GB with --depth=50
> - 1.3GB with --window=4000 --depth=32
> - 1.3GB with --depth=20
> - 821MB with --depth=250 for commits --before=2.years.ago, --depth=50
> for the rest
>
On Wed, Feb 19, 2014 at 3:59 AM, Junio C Hamano wrote:
> I didn't know --agressive was so aggressive myself, as I personally
> never use it. "git repack -a -d -f --depth=32 window=4000" is what I
> often use, but I suspect most people would not be patient enough for
> that 4k window.
>
> Let's do
Duy Nguyen writes:
> For old projects, commits older than 1-2 years is probably less often
> accessed and could use some aggressive packing.
I used to repack older part of history manually with a deeper depth,
mark the result with the .keep bit, and then repack the whole thing
again to have the
Christian Jaeger writes:
> Also, in "man git-gc" document --aggressive that it leads to slower
> *read* performance after the gc, I remember having red that option's
> docs when I ran it, and since it didn't mention that it makes reads
> slower, I didn't expect it to, and thus didn't remember thi
On Fri, Feb 21, 2014 at 06:35:06AM +0700, Duy Nguyen wrote:
> On the other hand, the size reduction is really nice (320MB vs 500MB).
> I don't know if we can do this, but does it make sense to apply
> --depth=250 for old commits only and shallow depth for recent commits?
>
> For old projects, comm
2014-02-20 23:35 GMT+00:00 Duy Nguyen :
> does it make sense to apply
> --depth=250 for old commits only
Just wondering: would it be difficult to fix the problems that lead to
worse than linear slowdown with the --depth? (I.e. adaptive cache/hash
table size.) If the performance difference between
On Thu, Feb 20, 2014 at 1:59 AM, Junio C Hamano wrote:
> Philippe Vaucher writes:
>
>>> fwiw this is the thread that added --depth=250
>>>
>>> http://thread.gmane.org/gmane.comp.gcc.devel/94565/focus=94626
>>
>> This post is quite interesting:
>> http://article.gmane.org/gmane.comp.gcc.devel/9463
David Kastrup writes:
> David Kastrup writes:
>
>> Duy Nguyen writes:
>>
>> Something's _really_ fishy about that cache behavior. Note that the
>> _system_ time goes up considerably, not just user time. Since the
>> packs are zlib-packed, it's reasonable that more I/O time is also
>> associat
David Kastrup writes:
> Duy Nguyen writes:
>
>> I can think of two improvements we could make, either increase cache
>> size dynamically (within limits) or make it configurable. If we have N
>> entries in worktree (both trees and blobs) and depth M, then we might
>> need to cache N*M objects for
Duy Nguyen writes:
> I can think of two improvements we could make, either increase cache
> size dynamically (within limits) or make it configurable. If we have N
> entries in worktree (both trees and blobs) and depth M, then we might
> need to cache N*M objects for it to be effective. Christian,
2014-02-19 10:14 GMT+00:00 Duy Nguyen :
> Christian, if you
> want to experiment this, update MAX_DELTA_CACHE in sha1_file.c and
> rebuild.
I don't have the time right now. (Perhaps next week?)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@
Philippe Vaucher writes:
>> fwiw this is the thread that added --depth=250
>>
>> http://thread.gmane.org/gmane.comp.gcc.devel/94565/focus=94626
>
> This post is quite interesting:
> http://article.gmane.org/gmane.comp.gcc.devel/94637
Yes, it most clearly says that --depth=250 was *not* a
recomme
On Wed, Feb 19, 2014 at 4:01 PM, David Kastrup wrote:
> Calling git blame via C-x v g is a rather important part of the
> workflow, and it's currently intolerable to work with on a number of
> files.
>
> While I'm fixing the basic shortcomings in builtin/blame.c itself, the
> operation "fetch the
On Wed, Feb 19, 2014 at 3:38 PM, Philippe Vaucher
wrote:
>> fwiw this is the thread that added --depth=250
>>
>> http://thread.gmane.org/gmane.comp.gcc.devel/94565/focus=94626
>
> This post is quite interesting:
> http://article.gmane.org/gmane.comp.gcc.devel/94637
Especially this part
-- 8< --
Philippe Vaucher writes:
>> fwiw this is the thread that added --depth=250
>>
>> http://thread.gmane.org/gmane.comp.gcc.devel/94565/focus=94626
>
> This post is quite interesting:
> http://article.gmane.org/gmane.comp.gcc.devel/94637
Yes. Of course I am prejudiced because I volunteered fixing g
> fwiw this is the thread that added --depth=250
>
> http://thread.gmane.org/gmane.comp.gcc.devel/94565/focus=94626
This post is quite interesting:
http://article.gmane.org/gmane.comp.gcc.devel/94637
Philippe
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
On Wed, Feb 19, 2014 at 7:10 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> Lower depth than default (50) does not sound "aggressive" to me, at
>> least from disk space utilization. I agree it should be configurable
>> though.
>
> Do you mean you want to keep "--aggressive" to mean "too aggr
Duy Nguyen writes:
> Lower depth than default (50) does not sound "aggressive" to me, at
> least from disk space utilization. I agree it should be configurable
> though.
Do you mean you want to keep "--aggressive" to mean "too aggressive
in resulting size, to the point that it is not useful to a
On Wed, Feb 19, 2014 at 3:59 AM, Junio C Hamano wrote:
> Let's do something like this first and then later make --depth
> configurable just like --width, perhaps? For "aggressive", I think
> the default width (hardcoded to 250 but configurable) is a bit too
> narrow.
>
> builtin/gc.c | 2 +-
> 1
Jonathan Nieder writes:
> David Kastrup wrote:
>> Duy Nguyen writes:
>
>>> Likely because --aggressive passes --depth=250 to pack-objects. Long
>>> delta chains could reduce pack size and increase I/O as well as zlib
>>> processing signficantly.
> [...]
>> Compression should reduce rather than i
2014-02-18 9:45 GMT+00:00 Duy Nguyen :
> Christian can try "git repack -adf"
That's what I already mentioned in my first mail is what I used to fix
the problem.
Here are some 'hard' numbers, FWIW:
- both ~/scr and swap are on the same SSD;
$ free
total used free sha
David Kastrup wrote:
> Duy Nguyen writes:
>> Likely because --aggressive passes --depth=250 to pack-objects. Long
>> delta chains could reduce pack size and increase I/O as well as zlib
>> processing signficantly.
[...]
> Compression should reduce rather than increase the total amount of
> reads.
Duy Nguyen writes:
> On Tue, Feb 18, 2014 at 3:55 PM, David Kastrup wrote:
>
>> I've seen the same with my ongoing work on git-blame with the current
>> Emacs Git mirror. Aggressive packing reduces the repository size to
>> about a quarter, but it blows up the system time (mainly I/O)
>> signif
On Tue, Feb 18, 2014 at 3:55 PM, David Kastrup wrote:
> Christian Jaeger writes:
>
>> I've got a repository where "git log --raw > _somefile" took a few
>> seconds in the past, but after an attempt at merging some commits that
>> were collected in a clone of the same repo that was created about a
Christian Jaeger writes:
> I've got a repository where "git log --raw > _somefile" took a few
> seconds in the past, but after an attempt at merging some commits that
> were collected in a clone of the same repo that was created about a
> year ago, I noticed that this command was now taking 3 min
Hi
I've got a repository where "git log --raw > _somefile" took a few
seconds in the past, but after an attempt at merging some commits that
were collected in a clone of the same repo that was created about a
year ago, I noticed that this command was now taking 3 minutes 7
seconds. "git gc", "git
31 matches
Mail list logo
