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
Duy Nguyen pclo...@gmail.com 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
David Kastrup d...@gnu.org writes:
Duy Nguyen pclo...@gmail.com 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
On Sat, Feb 22, 2014 at 3:53 PM, David Kastrup d...@gnu.org wrote:
David Kastrup d...@gnu.org writes:
Duy Nguyen pclo...@gmail.com 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
David Kastrup d...@gnu.org 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
On Sat, Feb 22, 2014 at 4:14 PM, Duy Nguyen pclo...@gmail.com wrote:
On Sat, Feb 22, 2014 at 3:53 PM, David Kastrup d...@gnu.org wrote:
David Kastrup d...@gnu.org writes:
Duy Nguyen pclo...@gmail.com writes:
OK with git://git.savannah.gnu.org/emacs.git we have
- a 209MB pack with
Christian Jaeger chr...@gmail.com 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
Duy Nguyen pclo...@gmail.com 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
On Wed, Feb 19, 2014 at 3:59 AM, Junio C Hamano gits...@pobox.com 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.
Duy Nguyen pclo...@gmail.com 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
David Kastrup d...@gnu.org writes:
Duy Nguyen pclo...@gmail.com 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
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
Duy Nguyen pclo...@gmail.com 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
On Thu, Feb 20, 2014 at 1:59 AM, Junio C Hamano gits...@pobox.com wrote:
Philippe Vaucher philippe.vauc...@gmail.com 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:
2014-02-20 23:35 GMT+00:00 Duy Nguyen pclo...@gmail.com:
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
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, commits
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 message
Philippe Vaucher philippe.vauc...@gmail.com 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
On Wed, Feb 19, 2014 at 3:38 PM, Philippe Vaucher
philippe.vauc...@gmail.com 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
On Wed, Feb 19, 2014 at 4:01 PM, David Kastrup d...@gnu.org 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
Philippe Vaucher philippe.vauc...@gmail.com 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
2014-02-19 10:14 GMT+00:00 Duy Nguyen pclo...@gmail.com:
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
Christian Jaeger chr...@gmail.com 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
On Tue, Feb 18, 2014 at 3:55 PM, David Kastrup d...@gnu.org wrote:
Christian Jaeger chr...@gmail.com 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
Duy Nguyen pclo...@gmail.com writes:
On Tue, Feb 18, 2014 at 3:55 PM, David Kastrup d...@gnu.org 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
David Kastrup wrote:
Duy Nguyen pclo...@gmail.com 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
2014-02-18 9:45 GMT+00:00 Duy Nguyen pclo...@gmail.com:
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
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
Duy Nguyen pclo...@gmail.com 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
On Wed, Feb 19, 2014 at 3:59 AM, Junio C Hamano gits...@pobox.com 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 |
Duy Nguyen pclo...@gmail.com 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
On Wed, Feb 19, 2014 at 7:10 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com 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
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 fsck,
31 matches
Mail list logo
