repack: propagate pack-objects options as strings
commitb861e235bc68e1c085e48d029579afbeeeec995c
authorJeff King <peff@peff.net>
Thu, 23 Jan 2014 01:30:13 +0000 (22 20:30 -0500)
committerJunio C Hamano <gitster@pobox.com>
Thu, 23 Jan 2014 18:34:53 +0000 (23 10:34 -0800)
treeed909eb28373eb467adba43bf31fb177cc0b237d
parentaa8bd519dbf044f4b54a365c9c80c6eb9a1ee2ea
repack: propagate pack-objects options as strings

In the original shell version of git-repack, any options
destined for pack-objects were left as strings, and passed
as a whole. Since the C rewrite in commit a1bbc6c (repack:
rewrite the shell script in C, 2013-09-15), we now parse
these values to integers internally, then reformat the
integers when passing the option to pack-objects.

This has the advantage that we catch format errors earlier
(i.e., when repack is invoked, rather than when pack-objects
is invoked).

It has three disadvantages, though:

  1. Our internal data types may not be the right size. In
     the case of "--window-memory" and "--max-pack-size",
     these are "unsigned long" in pack-objects, but we can
     only represent a regular "int".

  2. Our parsing routines might not be the same as those of
     pack-objects. For the two options above, pack-objects
     understands "100m" to mean "100 megabytes", but repack
     does not.

  3. We have to keep a sentinel value to know whether it is
     worth passing the option along. In the case of
     "--window-memory", we currently do not pass it if the
     value is "0". But that is a meaningful value to
     pack-objects, where it overrides any configured value.

We can fix all of these by simply passing the strings from
the user along to pack-objects verbatim. This does not
actually fix anything for "--depth" or "--window", but these
are converted, too, for consistency.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/repack.c