git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
May 24, 2011, 00:09 UTC
Message-ID
<7vlixxrmbr.fsf@alter.siamese.dyndns.org>
In-Reply-To
<1306111923-16859-8-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> writes:
Show 8 quoted lines
> 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.

Previous: Johan HerlandNext: Johan Herland
Message 17 of 26 in “[PATCHv4 00/10] Push limits”
  1. Johan HerlandMay 23, 2011
  2. 01/10 Update technical docs to reflect side-band-64k capability in receive-packJohan Herland, May 23, 2011
  3. 02/10 send-pack: Attempt to retrieve remote status even if pack-objects failsJohan Herland, May 23, 2011
  4. Junio C HamanoMay 23, 2011
  5. Johan HerlandMay 23, 2011
  6. 03/10 Tighten rules for matching server capabilities in server_supports()Johan Herland, May 23, 2011
  7. 04/10 receive-pack: Prepare for addition of the new 'limit-*' family of capabilitiesJohan Herland, May 23, 2011
  8. Junio C HamanoMay 23, 2011
  9. Johan HerlandMay 24, 2011
  10. 05/10 pack-objects: Teach new option --max-commit-count, limiting #commits in packJohan Herland, May 23, 2011
  11. Junio C HamanoMay 23, 2011
  12. Johan HerlandMay 24, 2011
  13. 06/10 send-pack/receive-pack: Allow server to refuse pushes with too many commitsJohan Herland, May 23, 2011
  14. Junio C HamanoMay 23, 2011
  15. Johan HerlandMay 24, 2011
  16. 07/10 pack-objects: Allow --max-pack-size to be used together with --stdoutJohan Herland, May 23, 2011
  17. Junio C HamanoMay 24, 2011
  18. Johan HerlandMay 24, 2011
  19. 08/10 send-pack/receive-pack: Allow server to refuse pushing too large packsJohan Herland, May 23, 2011
  20. Junio C HamanoMay 24, 2011
  21. 09/10 pack-objects: Estimate pack size; abort early if pack size limit is exceededJohan Herland, May 23, 2011
  22. Shawn PearceMay 23, 2011
  23. Johan HerlandMay 23, 2011
  24. Junio C HamanoMay 24, 2011
  25. Johan HerlandMay 24, 2011
  26. 10/10 receive-pack: Allow server to refuse pushes with too many objectsJohan Herland, May 23, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.