Re: [PATCH] Prevent megablobs from gunking up git packs

From: Junio C Hamano <junkio@cox.net>
Date: May 23, 2007, 22:08 UTC
Message-ID: <7v7iqz19d2.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46528A48.9050903@gmail.com>

Dana How <danahow@gmail.com> writes:

Show 7 quoted lines

> This patch implements the following:
> 1. git pack-objects takes a new --max-blob-size=N flag,
>    with the effect that only blobs less than N KB are written
>    to the packfiles(s).  If a blob was in a pack but violates
>    this limit (perhaps the packs were created by fast-import
>    or max-blob-size was reduced),  then a new loose object
>    is written out if needed so the data is not lost.

Why?

I really do not like that "write a new loose object" part without proper justification. From your description, I thought the most natural way to do this is to pretend you did not hear about large objects at all, by rejecting them early, perhaps inside add_object_entry() or inside get_object_details() -- either case you would do sha1_object_info() early instead of doing it in check_object().

By the way, is there fundamental reason that this needs to be "blob size" limit? Wouldn't "max-object-size" be more clean in theory, and work the same way in practice?

> 2. git repack inspects repack.maxblobsize .  If set,  its
>    value is passed to git pack-objects on the command line.
>    The user should change repack.maxblobsize ,  NOT specify
>    --max-blob-size=N .

Why not?

> This patch is on top of the earlier max-pack-size patch,
> because I thought I needed some behavior it supplied,
> but could be rebased on master if desired.

Your earlier "split according to max-pack-size" will hopefully be on master shortly.