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 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) {
> use_in
Junio C Hamano 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 fbd4a70 already
"brian m. carlson" 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 a significant performa
On Thu, Dec 11, 2014 at 10:46 AM, brian m. carlson
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 shallow clones; however, it
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 clones
6 matches
Mail list logo
