Re: [PATCHv4 07/10] pack-objects: Allow --max-pack-size to be used together with --stdout

On Tuesday 24 May 2011, Junio C Hamano wrote:

Johan Herland [off-list ref] writes:

quoted

Currently we refuse combining --max-pack-size with --stdout since
there's no way to make multiple packs when the pack is written to
stdout. However, we want to be able to limit the maximum size of the
pack created by --stdout (and abort pack-objects if we are unable to
meet that limit).

Therefore, when used together with --stdout, we reinterpret
--max-pack-size to indicate the maximum pack size which - if exceeded
- will cause pack-objects to abort with an error message.

I have to say that I am not very fond of this approach.

Imagine that in the future we may want to allow 32-bit receivers to say
"I want you to transfer data but I cannot handle very large packs
locally, so please send the packs in less-than-1GB chunks to make it
easier for me to store them in separate packfiles" (obviously this
involves a new protocol extension). The underlying machinery the sending
side would use would naturally want to say

	git pack-objects --max-pack-size=1GB --stdout

and you would see the data for the first pack, followed by the data for
the second pack, etc. on the standard output.  Such a receiver might also
want to say "You are not allowed to send more than 3GB at once to me" to
the sending side. What should the "pack-objects" command line look like?

I think you should keep the two concepts separate. max-pack-size should
stay the limit of each packfile "git pack-objects" is allowed to produce,
and there should be another option to specify the total pack data to be
produced, perhaps named --max-total-pack-size or something.

Ok. I will separate the concepts in the next iteration.

That would make your earlier "count" thing --max-total-commit-count; it
is perfectly fine that we do not plan to have the --max-commit-count
option that is per packfile.

Agreed.


...Johan

-- 
Johan Herland, [off-list ref]
www.herland.net