From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Stefan Beller <stefanbeller@googlemail.com>,
Siddharth Agarwal <sid0@fb.com>
Subject: [PATCH 3/3] repack: propagate pack-objects options as strings
Date: Wed, 22 Jan 2014 20:30:13 -0500 [thread overview]
Message-ID: <20140123013008.GC19472@sigill.intra.peff.net> (raw)
In-Reply-To: <20140123012656.GC17254@sigill.intra.peff.net>
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>
---
So we lose the advantage listed above. But I think the simplicity and
future-proofing is worth it (and in this case, we basically don't do
anything _except_ invoke pack-objects, so it is not like we do a bunch
of early work that has to be undone when we find out that the option is
bogus later on).
builtin/repack.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index 7f89c7c..6284846 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -130,9 +130,9 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
int pack_everything = 0;
int delete_redundant = 0;
const char *unpack_unreachable = NULL;
- int window = 0, window_memory = 0;
- int depth = 0;
- int max_pack_size = 0;
+ const char *window = NULL, *window_memory = NULL;
+ const char *depth = NULL;
+ const char *max_pack_size = NULL;
int no_reuse_delta = 0, no_reuse_object = 0;
int no_update_server_info = 0;
int quiet = 0;
@@ -157,13 +157,13 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
N_("pass --local to git-pack-objects")),
OPT_STRING(0, "unpack-unreachable", &unpack_unreachable, N_("approxidate"),
N_("with -A, do not loosen objects older than this")),
- OPT_INTEGER(0, "window", &window,
+ OPT_STRING(0, "window", &window, N_("n"),
N_("size of the window used for delta compression")),
- OPT_INTEGER(0, "window-memory", &window_memory,
+ OPT_STRING(0, "window-memory", &window_memory, N_("bytes"),
N_("same as the above, but limit memory size instead of entries count")),
- OPT_INTEGER(0, "depth", &depth,
+ OPT_STRING(0, "depth", &depth, N_("n"),
N_("limits the maximum delta depth")),
- OPT_INTEGER(0, "max-pack-size", &max_pack_size,
+ OPT_STRING(0, "max-pack-size", &max_pack_size, N_("bytes"),
N_("maximum size of each packfile")),
OPT_END()
};
@@ -185,13 +185,13 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
argv_array_push(&cmd_args, "--all");
argv_array_push(&cmd_args, "--reflog");
if (window)
- argv_array_pushf(&cmd_args, "--window=%u", window);
+ argv_array_pushf(&cmd_args, "--window=%s", window);
if (window_memory)
- argv_array_pushf(&cmd_args, "--window-memory=%u", window_memory);
+ argv_array_pushf(&cmd_args, "--window-memory=%s", window_memory);
if (depth)
- argv_array_pushf(&cmd_args, "--depth=%u", depth);
+ argv_array_pushf(&cmd_args, "--depth=%s", depth);
if (max_pack_size)
- argv_array_pushf(&cmd_args, "--max-pack-size=%u", max_pack_size);
+ argv_array_pushf(&cmd_args, "--max-pack-size=%s", max_pack_size);
if (no_reuse_delta)
argv_array_pushf(&cmd_args, "--no-reuse-delta");
if (no_reuse_object)
--
1.8.5.2.500.g8060133
next prev parent reply other threads:[~2014-01-23 1:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-21 22:48 git repack --max-pack-size broken in git-next Siddharth Agarwal
2014-01-21 23:01 ` Junio C Hamano
2014-01-21 23:26 ` Junio C Hamano
2014-01-22 19:58 ` [PATCH v2 0/2] Fix "repack --window-memory=4g" regression in 1.8.4 Junio C Hamano
2014-01-22 19:58 ` [PATCH v2 1/2] parse-options: refactor human-friendly-integer parser out of pack-objects Junio C Hamano
2014-01-22 19:58 ` [PATCH v2 2/2] repack: accept larger window-memory and max-pack-size Junio C Hamano
2014-01-23 1:06 ` Jeff King
2014-01-23 1:26 ` Jeff King
2014-01-23 1:27 ` [PATCH 1/3] repack: fix typo in max-pack-size option Jeff King
2014-01-23 1:28 ` [PATCH 2/3] repack: make parsed string options const-correct Jeff King
2014-01-23 1:30 ` Jeff King [this message]
2014-01-23 1:38 ` [PATCH 3/3] repack: propagate pack-objects options as strings Jeff King
2014-01-23 18:37 ` [PATCH v2 2/2] repack: accept larger window-memory and max-pack-size Junio C Hamano
2014-01-22 22:33 ` [PATCH v2 0/2] Fix "repack --window-memory=4g" regression in 1.8.4 Stefan Beller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140123013008.GC19472@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sid0@fb.com \
--cc=stefanbeller@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).