On Thu, Dec 11, 2014 at 11:26:47AM -0800, Junio C Hamano wrote:
The right approach would be more like allocating one more bit in
struct rev_info (call that edge_hint_aggressive), give a new option
--objects-edge-aggressive, and do something like
if (thin) {
On Thu, Dec 11, 2014 at 05:51:54PM +0700, Duy Nguyen wrote:
I'm glad it's now working better for you. Out of curiosity, have you
enabled pack bitmap on this repo? I would expect it to reduce time
some (or a lot) more, or we would find something to optimize further.
The client performs much,
On Thu, Dec 11, 2014 at 10:46 AM, brian m. carlson
sand...@crustytoothpaste.net wrote:
In commit fbd4a70 (list-objects: mark more commits as edges in
mark_edges_uninteresting - 2013-08-16), we made --thin much more
aggressive by reading lots more trees. This produces much smaller packs
for
brian m. carlson sand...@crustytoothpaste.net writes:
In commit fbd4a70 (list-objects: mark more commits as edges in
mark_edges_uninteresting - 2013-08-16), we made --thin much more
aggressive by reading lots more trees. This produces much smaller packs
for shallow clones; however, it causes
Junio C Hamano gits...@pobox.com writes:
This change affects non-clone/fetch uses of object listing depending
on the shallowness of the repository, and does not even care if it
is driven as part of the pack-object codepath, if I am reading it
correctly. It smells wrong.
The problematic
In commit fbd4a70 (list-objects: mark more commits as edges in
mark_edges_uninteresting - 2013-08-16), we made --thin much more
aggressive by reading lots more trees. This produces much smaller packs
for shallow clones; however, it causes a significant performance
regression for non-shallow
6 matches
Mail list logo
