git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).