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:
Show 31 quoted lines
> Johan Herland <johan@herland.net> writes:
> > 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.
--
Johan Herland, <johan@herland.net>
www.herland.net