[PATCH] git-{repack,pack-objects} accept --{pack,blob}-limit to control pack size

The motivations are to better support portable media,
older filesystems,  and larger repositories without
awkward enormous packfiles.

When --pack-limit[=N] is specified and --stdout is not,
all bytes in the resulting packfile(s) appear at offsets
less than N (which defaults to 1<<31).  The default
guarantees mmap(2) on 32b systems never sees signed off_t's.
The object stream may be broken into multiple packfiles
as a result,  each properly and conventionally built.

When --stdout is also specified,  all objects in the
resulting packfile(s) _start_ at offsets less than N.
All the packfiles appear concatenated on stdout,
and each has its object count set to 0.  The behavior
without --stdout cannot be duplicated here since
lseek(2) is not generally possible on stdout.  The end
of each pack in the concatenated whole can be detected by
asking,  just before reading each object,  if the next
20 bytes match the SHA-1 of what came before.
A future change might insert a null-byte EOF marker
(i.e. type=OBJ_NONE/length=0) before each pack's final SHA-1
or before only the final pack's SHA-1.

When --blob-limit=N is specified,  blobs whose uncompressed
size is greater than or equal to N are omitted from the pack(s).
If --pack-limit is specified, --blob-limit is not, and
--stdout is not,  then --blob-limit defaults to 1/4
of the --pack-limit.

To enable this,  csum-file.c now has the ability to rollback
a checksummed write (see sha1mark/sha1undo).

Signed-off-by: Dana L. How <redacted>
---
 builtin-pack-objects.c   |  300 ++++++++++++++++++++++++++++++++++++++--------
 builtin-unpack-objects.c |    2 +-
 csum-file.c              |   41 +++++++
 csum-file.h              |    6 +
 git-repack.sh            |   12 ++-
 http-fetch.c             |    2 +-
 http-push.c              |    2 +-
 index-pack.c             |    2 +-
 sha1_file.c              |    2 +-
 9 files changed, 307 insertions(+), 62 deletions(-)

[Full patch attached since gmail insists on wordwrap and eating ws]

Thanks,
-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell