Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes

From: Shawn O. Pearce <spearce@spearce.org>
Date: Feb 4, 2010, 17:24 UTC
Message-ID: <20100204172421.GA18548@spearce.org>
In-Reply-To: <7vtytxexjl.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines

> Subject: [PATCH] fast-import: count --max-pack-size in bytes
>  	if (!prefixcmp(option, "max-pack-size=")) {
> -		option_max_pack_size(option + 14);
> +		unsigned long v;
> +		if (!git_parse_ulong(option + 14, &v))
> +			return 0;
> +		if (v < 1024 * 1024) {
> +			warning("minimum max-pack-size is 1 MiB");
> +			v = 1024 * 1024;
> +		}
> +		max_packsize = v;

How about for a transition period we do:

  if (v < 8192) {
  	warning("max-pack-size is now in bytes, assuming %dm", v);
	v *= 1024 * 1024;
  }

So that existing users won't be completely broken if they are relying on this flag, and have some time to adjust.

Given the huge magnitude between the old sane value range, and the new sane value range, we can safely assume anything below a small number like 8192 is an old user, warn them, and assume old behavior.

A local pack smaller than 1 MiB is mostly pointless coming out of a tool like git repack or git fast-import, unless its a complete copy of the repository. So the old style calling convention of 4096 for 4 GiB would now imply a pack so small, we probably can't get more than 1 object per pack.

-- 
Shawn.