Thread (36 messages) flat view 36 messages, 6 authors, 2016-06-15

Re: [PATCHv3 4/9] pack-objects: Teach new option --max-object-count, similar to --max-pack-size

From: Johan Herland <hidden>
Date: 2016-06-15 22:51:15

Possibly related (same subject, not in this thread)

On Monday 16 May 2011, Shawn Pearce wrote:
On Sun, May 15, 2011 at 14:37, Johan Herland [off-list ref] wrote:
quoted
The new --max-object-count option behaves similarly to --max-pack-size,
except that the decision to split packs is determined by the number of
objects in the pack, and not by the size of the pack.
Like my note about pack size for this case... I think doing this
during writing is too late. We should be aborting the counting phase
if the output pack is to stdout and we are going to exceed this limit.
The patch actually does this in the --stdout case. Look at the last
hunk in builtin/pack-objects.c:
@@ -2349,6 +2366,9 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
 
        if (non_empty && !nr_result)
                return 0;
+       if (pack_to_stdout && object_count_limit && object_count_limit < nr_result)
+               die("unable to make pack within the object count limit"
+                       " (%lu objects)", object_count_limit);
        if (nr_result)
                prepare_pack(window, depth);
        write_pack_file();
So in the --stdout case, we have already aborted before we start
writing the pack (i.e. after the counting phase).

The commit message you quote above, are for the case where someone uses
--max-object-count _without_ --stdout, in which case we compare
nr_written to object_count_limit to determine when to split the pack.


...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help