2018-07-12 19:39:20 +00:00
|
|
|
#include "builtin.h"
|
|
|
|
#include "cache.h"
|
|
|
|
#include "config.h"
|
|
|
|
#include "parse-options.h"
|
2018-07-12 19:39:21 +00:00
|
|
|
#include "midx.h"
|
2019-03-21 19:36:13 +00:00
|
|
|
#include "trace2.h"
|
2021-03-30 15:04:11 +00:00
|
|
|
#include "object-store.h"
|
2018-07-12 19:39:20 +00:00
|
|
|
|
2021-03-30 15:03:54 +00:00
|
|
|
#define BUILTIN_MIDX_WRITE_USAGE \
|
midx: preliminary support for `--refs-snapshot`
To figure out which commits we can write a bitmap for, the multi-pack
index/bitmap code does a reachability traversal, marking any commit
which can be found in the MIDX as eligible to receive a bitmap.
This approach will cause a problem when multi-pack bitmaps are able to
be generated from `git repack`, since the reference tips can change
during the repack. Even though we ignore commits that don't exist in
the MIDX (when doing a scan of the ref tips), it's possible that a
commit in the MIDX reaches something that isn't.
This can happen when a multi-pack index contains some pack which refers
to loose objects (e.g., if a pack was pushed after starting the repack
but before generating the MIDX which depends on an object which is
stored as loose in the repository, and by definition isn't included in
the multi-pack index).
By taking a snapshot of the references before we start repacking, we can
close that race window. In the above scenario (where we have a packed
object pointing at a loose one), we'll either (a) take a snapshot of the
references before seeing the packed one, or (b) take it after, at which
point we can guarantee that the loose object will be packed and included
in the MIDX.
This patch does just that. It writes a temporary "reference snapshot",
which is a list of OIDs that are at the ref tips before writing a
multi-pack bitmap. References that are "preferred" (i.e,. are a suffix
of at least one value of the 'pack.preferBitmapTips' configuration) are
marked with a special '+'.
The format is simple: one line per commit at each tip, with an optional
'+' at the beginning (for preferred references, as described above).
When provided, the reference snapshot is used to drive bitmap selection
instead of the MIDX code doing its own traversal. When it isn't
provided, the usual traversal takes place instead.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-29 01:55:07 +00:00
|
|
|
N_("git multi-pack-index [<options>] write [--preferred-pack=<pack>]" \
|
|
|
|
"[--refs-snapshot=<path>]")
|
2021-03-30 15:03:54 +00:00
|
|
|
|
|
|
|
#define BUILTIN_MIDX_VERIFY_USAGE \
|
|
|
|
N_("git multi-pack-index [<options>] verify")
|
|
|
|
|
|
|
|
#define BUILTIN_MIDX_EXPIRE_USAGE \
|
|
|
|
N_("git multi-pack-index [<options>] expire")
|
|
|
|
|
|
|
|
#define BUILTIN_MIDX_REPACK_USAGE \
|
|
|
|
N_("git multi-pack-index [<options>] repack [--batch-size=<size>]")
|
|
|
|
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
static char const * const builtin_multi_pack_index_write_usage[] = {
|
|
|
|
BUILTIN_MIDX_WRITE_USAGE,
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
static char const * const builtin_multi_pack_index_verify_usage[] = {
|
|
|
|
BUILTIN_MIDX_VERIFY_USAGE,
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
static char const * const builtin_multi_pack_index_expire_usage[] = {
|
|
|
|
BUILTIN_MIDX_EXPIRE_USAGE,
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
static char const * const builtin_multi_pack_index_repack_usage[] = {
|
|
|
|
BUILTIN_MIDX_REPACK_USAGE,
|
|
|
|
NULL
|
|
|
|
};
|
2018-07-12 19:39:20 +00:00
|
|
|
static char const * const builtin_multi_pack_index_usage[] = {
|
2021-03-30 15:03:54 +00:00
|
|
|
BUILTIN_MIDX_WRITE_USAGE,
|
|
|
|
BUILTIN_MIDX_VERIFY_USAGE,
|
|
|
|
BUILTIN_MIDX_EXPIRE_USAGE,
|
|
|
|
BUILTIN_MIDX_REPACK_USAGE,
|
2018-07-12 19:39:20 +00:00
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct opts_multi_pack_index {
|
|
|
|
const char *object_dir;
|
2021-03-30 15:04:11 +00:00
|
|
|
const char *preferred_pack;
|
midx: preliminary support for `--refs-snapshot`
To figure out which commits we can write a bitmap for, the multi-pack
index/bitmap code does a reachability traversal, marking any commit
which can be found in the MIDX as eligible to receive a bitmap.
This approach will cause a problem when multi-pack bitmaps are able to
be generated from `git repack`, since the reference tips can change
during the repack. Even though we ignore commits that don't exist in
the MIDX (when doing a scan of the ref tips), it's possible that a
commit in the MIDX reaches something that isn't.
This can happen when a multi-pack index contains some pack which refers
to loose objects (e.g., if a pack was pushed after starting the repack
but before generating the MIDX which depends on an object which is
stored as loose in the repository, and by definition isn't included in
the multi-pack index).
By taking a snapshot of the references before we start repacking, we can
close that race window. In the above scenario (where we have a packed
object pointing at a loose one), we'll either (a) take a snapshot of the
references before seeing the packed one, or (b) take it after, at which
point we can guarantee that the loose object will be packed and included
in the MIDX.
This patch does just that. It writes a temporary "reference snapshot",
which is a list of OIDs that are at the ref tips before writing a
multi-pack bitmap. References that are "preferred" (i.e,. are a suffix
of at least one value of the 'pack.preferBitmapTips' configuration) are
marked with a special '+'.
The format is simple: one line per commit at each tip, with an optional
'+' at the beginning (for preferred references, as described above).
When provided, the reference snapshot is used to drive bitmap selection
instead of the MIDX code doing its own traversal. When it isn't
provided, the usual traversal takes place instead.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-29 01:55:07 +00:00
|
|
|
const char *refs_snapshot;
|
2019-06-10 23:35:26 +00:00
|
|
|
unsigned long batch_size;
|
2021-03-30 15:03:47 +00:00
|
|
|
unsigned flags;
|
2021-09-29 01:55:04 +00:00
|
|
|
int stdin_packs;
|
2018-07-12 19:39:20 +00:00
|
|
|
} opts;
|
|
|
|
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
static struct option common_opts[] = {
|
|
|
|
OPT_FILENAME(0, "object-dir", &opts.object_dir,
|
|
|
|
N_("object directory containing set of packfile and pack-index pairs")),
|
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct option *add_common_options(struct option *prev)
|
|
|
|
{
|
|
|
|
return parse_options_concat(common_opts, prev);
|
|
|
|
}
|
|
|
|
|
2021-09-14 22:06:06 +00:00
|
|
|
static int git_multi_pack_index_write_config(const char *var, const char *value,
|
|
|
|
void *cb)
|
|
|
|
{
|
|
|
|
if (!strcmp(var, "pack.writebitmaphashcache")) {
|
|
|
|
if (git_config_bool(var, value))
|
|
|
|
opts.flags |= MIDX_WRITE_BITMAP_HASH_CACHE;
|
|
|
|
else
|
|
|
|
opts.flags &= ~MIDX_WRITE_BITMAP_HASH_CACHE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We should never make a fall-back call to 'git_default_config', since
|
|
|
|
* this was already called in 'cmd_multi_pack_index()'.
|
|
|
|
*/
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-09-29 01:55:04 +00:00
|
|
|
static void read_packs_from_stdin(struct string_list *to)
|
|
|
|
{
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
while (strbuf_getline(&buf, stdin) != EOF)
|
|
|
|
string_list_append(to, buf.buf);
|
|
|
|
string_list_sort(to);
|
|
|
|
|
|
|
|
strbuf_release(&buf);
|
|
|
|
}
|
|
|
|
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
static int cmd_multi_pack_index_write(int argc, const char **argv)
|
|
|
|
{
|
2021-03-30 15:04:11 +00:00
|
|
|
struct option *options;
|
|
|
|
static struct option builtin_multi_pack_index_write_options[] = {
|
|
|
|
OPT_STRING(0, "preferred-pack", &opts.preferred_pack,
|
|
|
|
N_("preferred-pack"),
|
|
|
|
N_("pack for reuse when computing a multi-pack bitmap")),
|
2021-08-31 20:52:24 +00:00
|
|
|
OPT_BIT(0, "bitmap", &opts.flags, N_("write multi-pack bitmap"),
|
|
|
|
MIDX_WRITE_BITMAP | MIDX_WRITE_REV_INDEX),
|
2021-09-20 21:39:19 +00:00
|
|
|
OPT_BIT(0, "progress", &opts.flags,
|
|
|
|
N_("force progress reporting"), MIDX_PROGRESS),
|
2021-09-29 01:55:04 +00:00
|
|
|
OPT_BOOL(0, "stdin-packs", &opts.stdin_packs,
|
|
|
|
N_("write multi-pack index containing only given indexes")),
|
midx: preliminary support for `--refs-snapshot`
To figure out which commits we can write a bitmap for, the multi-pack
index/bitmap code does a reachability traversal, marking any commit
which can be found in the MIDX as eligible to receive a bitmap.
This approach will cause a problem when multi-pack bitmaps are able to
be generated from `git repack`, since the reference tips can change
during the repack. Even though we ignore commits that don't exist in
the MIDX (when doing a scan of the ref tips), it's possible that a
commit in the MIDX reaches something that isn't.
This can happen when a multi-pack index contains some pack which refers
to loose objects (e.g., if a pack was pushed after starting the repack
but before generating the MIDX which depends on an object which is
stored as loose in the repository, and by definition isn't included in
the multi-pack index).
By taking a snapshot of the references before we start repacking, we can
close that race window. In the above scenario (where we have a packed
object pointing at a loose one), we'll either (a) take a snapshot of the
references before seeing the packed one, or (b) take it after, at which
point we can guarantee that the loose object will be packed and included
in the MIDX.
This patch does just that. It writes a temporary "reference snapshot",
which is a list of OIDs that are at the ref tips before writing a
multi-pack bitmap. References that are "preferred" (i.e,. are a suffix
of at least one value of the 'pack.preferBitmapTips' configuration) are
marked with a special '+'.
The format is simple: one line per commit at each tip, with an optional
'+' at the beginning (for preferred references, as described above).
When provided, the reference snapshot is used to drive bitmap selection
instead of the MIDX code doing its own traversal. When it isn't
provided, the usual traversal takes place instead.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-29 01:55:07 +00:00
|
|
|
OPT_FILENAME(0, "refs-snapshot", &opts.refs_snapshot,
|
|
|
|
N_("refs snapshot for selecting bitmap commits")),
|
2021-03-30 15:04:11 +00:00
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
|
2021-09-14 22:06:06 +00:00
|
|
|
opts.flags |= MIDX_WRITE_BITMAP_HASH_CACHE;
|
|
|
|
|
|
|
|
git_config(git_multi_pack_index_write_config, NULL);
|
|
|
|
|
2021-03-30 15:04:11 +00:00
|
|
|
options = add_common_options(builtin_multi_pack_index_write_options);
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
|
2021-03-30 15:04:01 +00:00
|
|
|
trace2_cmd_mode(argv[0]);
|
|
|
|
|
2021-09-20 21:39:19 +00:00
|
|
|
if (isatty(2))
|
|
|
|
opts.flags |= MIDX_PROGRESS;
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
argc = parse_options(argc, argv, NULL,
|
|
|
|
options, builtin_multi_pack_index_write_usage,
|
|
|
|
PARSE_OPT_KEEP_UNKNOWN);
|
|
|
|
if (argc)
|
|
|
|
usage_with_options(builtin_multi_pack_index_write_usage,
|
|
|
|
options);
|
|
|
|
|
2021-03-30 15:04:11 +00:00
|
|
|
FREE_AND_NULL(options);
|
|
|
|
|
2021-09-29 01:55:04 +00:00
|
|
|
if (opts.stdin_packs) {
|
|
|
|
struct string_list packs = STRING_LIST_INIT_DUP;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
read_packs_from_stdin(&packs);
|
|
|
|
|
|
|
|
ret = write_midx_file_only(opts.object_dir, &packs,
|
midx: preliminary support for `--refs-snapshot`
To figure out which commits we can write a bitmap for, the multi-pack
index/bitmap code does a reachability traversal, marking any commit
which can be found in the MIDX as eligible to receive a bitmap.
This approach will cause a problem when multi-pack bitmaps are able to
be generated from `git repack`, since the reference tips can change
during the repack. Even though we ignore commits that don't exist in
the MIDX (when doing a scan of the ref tips), it's possible that a
commit in the MIDX reaches something that isn't.
This can happen when a multi-pack index contains some pack which refers
to loose objects (e.g., if a pack was pushed after starting the repack
but before generating the MIDX which depends on an object which is
stored as loose in the repository, and by definition isn't included in
the multi-pack index).
By taking a snapshot of the references before we start repacking, we can
close that race window. In the above scenario (where we have a packed
object pointing at a loose one), we'll either (a) take a snapshot of the
references before seeing the packed one, or (b) take it after, at which
point we can guarantee that the loose object will be packed and included
in the MIDX.
This patch does just that. It writes a temporary "reference snapshot",
which is a list of OIDs that are at the ref tips before writing a
multi-pack bitmap. References that are "preferred" (i.e,. are a suffix
of at least one value of the 'pack.preferBitmapTips' configuration) are
marked with a special '+'.
The format is simple: one line per commit at each tip, with an optional
'+' at the beginning (for preferred references, as described above).
When provided, the reference snapshot is used to drive bitmap selection
instead of the MIDX code doing its own traversal. When it isn't
provided, the usual traversal takes place instead.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-29 01:55:07 +00:00
|
|
|
opts.preferred_pack,
|
|
|
|
opts.refs_snapshot, opts.flags);
|
2021-09-29 01:55:04 +00:00
|
|
|
|
|
|
|
string_list_clear(&packs, 0);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
}
|
2021-03-30 15:04:11 +00:00
|
|
|
return write_midx_file(opts.object_dir, opts.preferred_pack,
|
midx: preliminary support for `--refs-snapshot`
To figure out which commits we can write a bitmap for, the multi-pack
index/bitmap code does a reachability traversal, marking any commit
which can be found in the MIDX as eligible to receive a bitmap.
This approach will cause a problem when multi-pack bitmaps are able to
be generated from `git repack`, since the reference tips can change
during the repack. Even though we ignore commits that don't exist in
the MIDX (when doing a scan of the ref tips), it's possible that a
commit in the MIDX reaches something that isn't.
This can happen when a multi-pack index contains some pack which refers
to loose objects (e.g., if a pack was pushed after starting the repack
but before generating the MIDX which depends on an object which is
stored as loose in the repository, and by definition isn't included in
the multi-pack index).
By taking a snapshot of the references before we start repacking, we can
close that race window. In the above scenario (where we have a packed
object pointing at a loose one), we'll either (a) take a snapshot of the
references before seeing the packed one, or (b) take it after, at which
point we can guarantee that the loose object will be packed and included
in the MIDX.
This patch does just that. It writes a temporary "reference snapshot",
which is a list of OIDs that are at the ref tips before writing a
multi-pack bitmap. References that are "preferred" (i.e,. are a suffix
of at least one value of the 'pack.preferBitmapTips' configuration) are
marked with a special '+'.
The format is simple: one line per commit at each tip, with an optional
'+' at the beginning (for preferred references, as described above).
When provided, the reference snapshot is used to drive bitmap selection
instead of the MIDX code doing its own traversal. When it isn't
provided, the usual traversal takes place instead.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-29 01:55:07 +00:00
|
|
|
opts.refs_snapshot, opts.flags);
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int cmd_multi_pack_index_verify(int argc, const char **argv)
|
|
|
|
{
|
2021-09-20 21:39:19 +00:00
|
|
|
struct option *options;
|
|
|
|
static struct option builtin_multi_pack_index_verify_options[] = {
|
|
|
|
OPT_BIT(0, "progress", &opts.flags,
|
|
|
|
N_("force progress reporting"), MIDX_PROGRESS),
|
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
options = add_common_options(builtin_multi_pack_index_verify_options);
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
|
2021-03-30 15:04:01 +00:00
|
|
|
trace2_cmd_mode(argv[0]);
|
|
|
|
|
2021-09-20 21:39:19 +00:00
|
|
|
if (isatty(2))
|
|
|
|
opts.flags |= MIDX_PROGRESS;
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
argc = parse_options(argc, argv, NULL,
|
|
|
|
options, builtin_multi_pack_index_verify_usage,
|
|
|
|
PARSE_OPT_KEEP_UNKNOWN);
|
|
|
|
if (argc)
|
|
|
|
usage_with_options(builtin_multi_pack_index_verify_usage,
|
|
|
|
options);
|
|
|
|
|
2021-10-26 21:01:18 +00:00
|
|
|
FREE_AND_NULL(options);
|
|
|
|
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
return verify_midx_file(the_repository, opts.object_dir, opts.flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int cmd_multi_pack_index_expire(int argc, const char **argv)
|
|
|
|
{
|
2021-09-20 21:39:19 +00:00
|
|
|
struct option *options;
|
|
|
|
static struct option builtin_multi_pack_index_expire_options[] = {
|
|
|
|
OPT_BIT(0, "progress", &opts.flags,
|
|
|
|
N_("force progress reporting"), MIDX_PROGRESS),
|
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
options = add_common_options(builtin_multi_pack_index_expire_options);
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
|
2021-03-30 15:04:01 +00:00
|
|
|
trace2_cmd_mode(argv[0]);
|
|
|
|
|
2021-09-20 21:39:19 +00:00
|
|
|
if (isatty(2))
|
|
|
|
opts.flags |= MIDX_PROGRESS;
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
argc = parse_options(argc, argv, NULL,
|
|
|
|
options, builtin_multi_pack_index_expire_usage,
|
|
|
|
PARSE_OPT_KEEP_UNKNOWN);
|
|
|
|
if (argc)
|
|
|
|
usage_with_options(builtin_multi_pack_index_expire_usage,
|
|
|
|
options);
|
|
|
|
|
2021-10-26 21:01:18 +00:00
|
|
|
FREE_AND_NULL(options);
|
|
|
|
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
return expire_midx_packs(the_repository, opts.object_dir, opts.flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int cmd_multi_pack_index_repack(int argc, const char **argv)
|
2018-07-12 19:39:20 +00:00
|
|
|
{
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
struct option *options;
|
|
|
|
static struct option builtin_multi_pack_index_repack_options[] = {
|
2019-06-10 23:35:26 +00:00
|
|
|
OPT_MAGNITUDE(0, "batch-size", &opts.batch_size,
|
|
|
|
N_("during repack, collect pack-files of smaller size into a batch that is larger than this size")),
|
2021-09-20 21:39:19 +00:00
|
|
|
OPT_BIT(0, "progress", &opts.flags,
|
|
|
|
N_("force progress reporting"), MIDX_PROGRESS),
|
2018-07-12 19:39:20 +00:00
|
|
|
OPT_END(),
|
|
|
|
};
|
|
|
|
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
options = add_common_options(builtin_multi_pack_index_repack_options);
|
|
|
|
|
2021-03-30 15:04:01 +00:00
|
|
|
trace2_cmd_mode(argv[0]);
|
|
|
|
|
2021-09-20 21:39:19 +00:00
|
|
|
if (isatty(2))
|
|
|
|
opts.flags |= MIDX_PROGRESS;
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
argc = parse_options(argc, argv, NULL,
|
|
|
|
options,
|
|
|
|
builtin_multi_pack_index_repack_usage,
|
|
|
|
PARSE_OPT_KEEP_UNKNOWN);
|
|
|
|
if (argc)
|
|
|
|
usage_with_options(builtin_multi_pack_index_repack_usage,
|
|
|
|
options);
|
|
|
|
|
|
|
|
FREE_AND_NULL(options);
|
|
|
|
|
|
|
|
return midx_repack(the_repository, opts.object_dir,
|
|
|
|
(size_t)opts.batch_size, opts.flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
int cmd_multi_pack_index(int argc, const char **argv,
|
|
|
|
const char *prefix)
|
|
|
|
{
|
|
|
|
struct option *builtin_multi_pack_index_options = common_opts;
|
|
|
|
|
2018-07-12 19:39:20 +00:00
|
|
|
git_config(git_default_config, NULL);
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, prefix,
|
|
|
|
builtin_multi_pack_index_options,
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
builtin_multi_pack_index_usage,
|
|
|
|
PARSE_OPT_STOP_AT_NON_OPTION);
|
2018-07-12 19:39:20 +00:00
|
|
|
|
|
|
|
if (!opts.object_dir)
|
|
|
|
opts.object_dir = get_object_directory();
|
|
|
|
|
2021-08-23 12:30:18 +00:00
|
|
|
if (!argc)
|
2021-03-30 15:04:04 +00:00
|
|
|
goto usage;
|
2018-07-12 19:39:21 +00:00
|
|
|
|
2019-06-10 23:35:26 +00:00
|
|
|
if (!strcmp(argv[0], "repack"))
|
builtin/multi-pack-index.c: split sub-commands
Handle sub-commands of the 'git multi-pack-index' builtin (e.g.,
"write", "repack", etc.) separately from one another. This allows
sub-commands with unique options, without forcing cmd_multi_pack_index()
to reject invalid combinations itself.
This comes at the cost of some duplication and boilerplate. Luckily, the
duplication is reduced to a minimum, since common options are shared
among sub-commands due to a suggestion by Ævar. (Sub-commands do have to
retain the common options, too, since this builtin accepts common
options on either side of the sub-command).
Roughly speaking, cmd_multi_pack_index() parses options (including
common ones), and stops at the first non-option, which is the
sub-command. It then dispatches to the appropriate sub-command, which
parses the remaining options (also including common options).
Unknown options are kept by the sub-commands in order to detect their
presence (and complain that too many arguments were given).
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-30 15:03:57 +00:00
|
|
|
return cmd_multi_pack_index_repack(argc, argv);
|
|
|
|
else if (!strcmp(argv[0], "write"))
|
|
|
|
return cmd_multi_pack_index_write(argc, argv);
|
|
|
|
else if (!strcmp(argv[0], "verify"))
|
|
|
|
return cmd_multi_pack_index_verify(argc, argv);
|
|
|
|
else if (!strcmp(argv[0], "expire"))
|
|
|
|
return cmd_multi_pack_index_expire(argc, argv);
|
2021-08-23 12:30:18 +00:00
|
|
|
|
|
|
|
error(_("unrecognized subcommand: %s"), argv[0]);
|
2021-07-19 17:18:49 +00:00
|
|
|
usage:
|
2021-08-23 12:30:18 +00:00
|
|
|
usage_with_options(builtin_multi_pack_index_usage,
|
|
|
|
builtin_multi_pack_index_options);
|
2018-07-12 19:39:20 +00:00
|
|
|
}
|