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

Johan Herland [off-list ref] 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.

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.

Some people may kvetch about "inconsistency", but I think this is a
justifiable inconsistency, as "You should refrain from putting more than
this number of commits in a single pack" is a limit that does not have any
practical use, while "You should refrain from sending more than this
number of commits in total" does.

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