# [PATCH] Revert "pack-objects: fix pack generation when using pack_size_limit" 3 messages from 2010-02-08 to 2010-02-08. Participants: Nicolas Pitre, Junio C Hamano. Thread: https://gitlist.dev/t/22568 ## Nicolas Pitre, 2010-02-08 15:39 Subject: [PATCH] Revert "pack-objects: fix pack generation when using pack_size_limit" Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.1002081032530.1681%40xanadu.home ``` This reverts most of commit a2430dde8ceaaaabf05937438249397b883ca77a. That commit made the situation better for repositories with relatively small number of objects. However with many objects and a small pack size limit, the time required to complete the repack tends towards O(n^2), or even much worse with long delta chains. Signed-off-by: Nicolas Pitre --- Fixing this doesn't appear to be as trivial as I initially thought. Although I do have some ideas, they're not appropriate so late in the -rc period. diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c index dcfe62a..e1d3adf 100644 --- a/builtin-pack-objects.c +++ b/builtin-pack-objects.c @@ -445,13 +445,9 @@ static int write_one(struct sha1file *f, if (e->idx.offset || e->preferred_base) return -1; - /* - * If we are deltified, attempt to write out base object first. - * If that fails due to the pack size limit then the current - * object might still possibly fit undeltified within that limit. - */ - if (e->delta) - write_one(f, e->delta, offset); + /* if we are deltified, write out base object first. */ + if (e->delta && !write_one(f, e->delta, offset)) + return 0; e->idx.offset = *offset; size = write_object(f, e, *offset); @@ -505,9 +501,11 @@ static void write_pack_file(void) sha1write(f, &hdr, sizeof(hdr)); offset = sizeof(hdr); nr_written = 0; - for (i = 0; i < nr_objects; i++) - if (write_one(f, objects + i, &offset) == 1) - display_progress(progress_state, written); + for (; i < nr_objects; i++) { + if (!write_one(f, objects + i, &offset)) + break; + display_progress(progress_state, written); + } /* * Did we write the wrong # entries in the header? @@ -582,7 +580,7 @@ static void write_pack_file(void) written_list[j]->offset = (off_t)-1; } nr_remaining -= nr_written; - } while (nr_remaining); + } while (nr_remaining && i < nr_objects); free(written_list); stop_progress(&progress_state); diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh index 1058d98..7649b81 100755 --- a/t/t5300-pack-object.sh +++ b/t/t5300-pack-object.sh @@ -389,7 +389,7 @@ test_expect_success 'verify resulting packs' ' test_expect_success 'tolerate packsizelimit smaller than biggest object' ' git config pack.packSizeLimit 1 && packname_11=$(git pack-objects test-11 URL: https://gitlist.dev/e/7v3a1bpqqq.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Nicolas Pitre writes: > This reverts most of commit a2430dde8ceaaaabf05937438249397b883ca77a. > > That commit made the situation better for repositories with relatively > small number of objects. However with many objects and a small pack size > limit, the time required to complete the repack tends towards O(n^2), > or even much worse with long delta chains. > > Signed-off-by: Nicolas Pitre > --- > > Fixing this doesn't appear to be as trivial as I initially thought. > Although I do have some ideas, they're not appropriate so late in > the -rc period. Ok, so the idea is what a2430dd tried is an issue worth addressing but the particular execution wasn't good? We revert it for now, but we will try again after the release, perhaps doing it differently? I agree with it if that is your intention, but "Most of" bugs me a bit. ``` ## Nicolas Pitre, 2010-02-08 18:11 Subject: Re: [PATCH] Revert "pack-objects: fix pack generation when using pack_size_limit" Message-ID: URL: https://gitlist.dev/e/alpine.LFD.2.00.1002081306420.1681%40xanadu.home In-Reply-To: <7v3a1bpqqq.fsf@alter.siamese.dyndns.org> ``` On Mon, 8 Feb 2010, Junio C Hamano wrote: > Nicolas Pitre writes: > > > This reverts most of commit a2430dde8ceaaaabf05937438249397b883ca77a. > > > > That commit made the situation better for repositories with relatively > > small number of objects. However with many objects and a small pack size > > limit, the time required to complete the repack tends towards O(n^2), > > or even much worse with long delta chains. > > > > Signed-off-by: Nicolas Pitre > > --- > > > > Fixing this doesn't appear to be as trivial as I initially thought. > > Although I do have some ideas, they're not appropriate so late in > > the -rc period. > > Ok, so the idea is what a2430dd tried is an issue worth addressing but the > particular execution wasn't good? We revert it for now, but we will try > again after the release, perhaps doing it differently? Exact. I did try a few things in the hope that the "fix" would have been trivial enough to merge now but none of that worked satisfactorily. > I agree with it if that is your intention, but "Most of" bugs me a bit. It's not a straight revert in the sense that I left in some cleanups and left out the redundant self consistency check. Only the significant parts were reverted. Nicolas ```