2007-07-15 01:14:45 +02:00
|
|
|
#include "builtin.h"
|
2020-07-28 22:23:39 +02:00
|
|
|
#include "strvec.h"
|
2019-11-10 21:41:24 +01:00
|
|
|
#include "parse-options.h"
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:59:14 +01:00
|
|
|
#include "cache.h"
|
2007-09-11 05:03:15 +02:00
|
|
|
#include "bundle.h"
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:59:14 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Basic handler for bundle files to connect repositories via sneakernet.
|
|
|
|
* Invocation must include action.
|
|
|
|
* This function can create a bundle or provide information on an existing
|
2008-08-30 13:12:53 +02:00
|
|
|
* bundle supporting "fetch", "pull", and "ls-remote".
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:59:14 +01:00
|
|
|
*/
|
|
|
|
|
2022-10-13 17:38:58 +02:00
|
|
|
#define BUILTIN_BUNDLE_CREATE_USAGE \
|
bundle: turn on --all-progress-implied by default
In 79862b6b77c (bundle-create: progress output control, 2019-11-10),
"bundle create" learned about the --all-progress and
--all-progress-implied options, which were copied from pack-objects.
I think these were a mistake.
In pack-objects, "all-progress-implied" is about switching the behavior
between a regular on-disk "git repack" and the use of pack-objects for
push/fetch (where a fetch does not want progress from the server during
the write stage; the client will print progress as it receives the
data). But there's no such distinction for bundles. Prior to
79862b6b77c, we always printed the write stage. Afterwards, a vanilla:
git bundle create foo.bundle
omits the write progress, appearing to hang (especially if your
repository is large or your disk is slow). That seems like a regression.
It's possible that the flexibility to disable the write-phase progress
_could_ be useful for bundle. E.g., if you did something like:
ssh some-host git bundle create foo.bundle |
git bundle unbundle
But if you are running both in real-time, why are you using bundles in
the first place? You're better off doing a real fetch.
But even if we did want to support that, it should be the exception, and
vanilla "bundle create" should display the full progress. So we'd want
to name the option "--no-write-progress" or something.
The "--all-progress" option itself is even worse. It exists in
pack-objects only for historical reasons. It's a mistake because it
implies "--progress", and we added "--all-progress-implied" to fix that.
There is no reason to propagate that mistake to new commands.
Likewise, the documentation for these options was pulled from
pack-objects. But it doesn't make any sense in this context. It talks
about "--stdout", but that is not even an option that git-bundle
supports.
This patch flips the default for "--all-progress-implied" back to
"true", fixing the regression in 79862b6b77c. This turns that option
into a noop, and means that "--all-progress" is really the same as
"--progress". We _could_ drop them completely, but since they've been
shipped with Git since v2.25.0, it's polite to continue accepting them.
I didn't implement any sort of "--no-write-progress" here. I'm not at
all convinced it's necessary, and the discussion from the original
thread:
https://lore.kernel.org/git/20191110204126.30553-2-robbat2@gentoo.org/
shows that that the main focus was on getting --progress and --quiet
support, and not any kind of clever "real-time bundle over the network"
feature. But technically this patch is making it impossible to do
something that you _could_ do post-79862b6b77c.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:55:13 +01:00
|
|
|
N_("git bundle create [-q | --quiet | --progress]\n" \
|
2022-10-13 17:39:16 +02:00
|
|
|
" [--version=<version>] <file> <git-rev-list-args>")
|
2022-10-13 17:38:58 +02:00
|
|
|
#define BUILTIN_BUNDLE_VERIFY_USAGE \
|
2022-10-13 17:39:16 +02:00
|
|
|
N_("git bundle verify [-q | --quiet] <file>")
|
2022-10-13 17:38:58 +02:00
|
|
|
#define BUILTIN_BUNDLE_LIST_HEADS_USAGE \
|
|
|
|
N_("git bundle list-heads <file> [<refname>...]")
|
|
|
|
#define BUILTIN_BUNDLE_UNBUNDLE_USAGE \
|
2022-10-13 17:39:16 +02:00
|
|
|
N_("git bundle unbundle [--progress] <file> [<refname>...]")
|
2022-10-13 17:38:58 +02:00
|
|
|
|
|
|
|
static char const * const builtin_bundle_usage[] = {
|
|
|
|
BUILTIN_BUNDLE_CREATE_USAGE,
|
|
|
|
BUILTIN_BUNDLE_VERIFY_USAGE,
|
|
|
|
BUILTIN_BUNDLE_LIST_HEADS_USAGE,
|
|
|
|
BUILTIN_BUNDLE_UNBUNDLE_USAGE,
|
|
|
|
NULL,
|
2019-11-10 21:41:24 +01:00
|
|
|
};
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:59:14 +01:00
|
|
|
|
2019-11-10 21:41:24 +01:00
|
|
|
static const char * const builtin_bundle_create_usage[] = {
|
2022-10-13 17:38:58 +02:00
|
|
|
BUILTIN_BUNDLE_CREATE_USAGE,
|
2022-10-13 17:38:57 +02:00
|
|
|
NULL
|
2019-11-10 21:41:24 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
static const char * const builtin_bundle_verify_usage[] = {
|
2022-10-13 17:38:58 +02:00
|
|
|
BUILTIN_BUNDLE_VERIFY_USAGE,
|
2022-10-13 17:38:57 +02:00
|
|
|
NULL
|
2019-11-10 21:41:24 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
static const char * const builtin_bundle_list_heads_usage[] = {
|
2022-10-13 17:38:58 +02:00
|
|
|
BUILTIN_BUNDLE_LIST_HEADS_USAGE,
|
2022-10-13 17:38:57 +02:00
|
|
|
NULL
|
2019-11-10 21:41:24 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
static const char * const builtin_bundle_unbundle_usage[] = {
|
2022-10-13 17:38:58 +02:00
|
|
|
BUILTIN_BUNDLE_UNBUNDLE_USAGE,
|
2022-10-13 17:38:57 +02:00
|
|
|
NULL
|
2019-11-10 21:41:24 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
static int parse_options_cmd_bundle(int argc,
|
|
|
|
const char **argv,
|
|
|
|
const char* prefix,
|
|
|
|
const char * const usagestr[],
|
|
|
|
const struct option options[],
|
2021-07-02 11:57:30 +02:00
|
|
|
char **bundle_file) {
|
2022-12-27 19:39:09 +01:00
|
|
|
argc = parse_options(argc, argv, NULL, options, usagestr,
|
2019-11-10 21:41:24 +01:00
|
|
|
PARSE_OPT_STOP_AT_NON_OPTION);
|
2022-12-27 19:39:09 +01:00
|
|
|
if (!argc)
|
2022-12-27 19:39:10 +01:00
|
|
|
usage_msg_opt(_("need a <file> argument"), usagestr, options);
|
bundle: don't blindly apply prefix_filename() to "-"
A user can specify a filename to a command from the command line,
either as the value given to a command line option, or a command
line argument. When it is given as a relative filename, in the
user's mind, it is relative to the directory "git" was started from,
but by the time the filename is used, "git" would almost always have
chdir()'ed up to the root level of the working tree.
The given filename, if it is relative, needs to be prefixed with the
path to the current directory, and it typically is done by calling
prefix_filename() helper function. For commands that can also take
"-" to use the standard input or the standard output, however, this
needs to be done with care.
"git bundle create" uses the next word on the command line as the
output filename, and can take "-" to mean "write to the standard
output". It blindly called prefix_filename(), so running it in a
subdirectory did not quite work as expected.
Introduce a new helper, prefix_filename_except_for_dash(), and use
it to help "git bundle create" codepath.
Reported-by: Michael Henry
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:27:56 +01:00
|
|
|
*bundle_file = prefix_filename_except_for_dash(prefix, argv[0]);
|
2022-12-27 19:39:09 +01:00
|
|
|
return argc;
|
2019-11-10 21:41:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static int cmd_bundle_create(int argc, const char **argv, const char *prefix) {
|
bundle: turn on --all-progress-implied by default
In 79862b6b77c (bundle-create: progress output control, 2019-11-10),
"bundle create" learned about the --all-progress and
--all-progress-implied options, which were copied from pack-objects.
I think these were a mistake.
In pack-objects, "all-progress-implied" is about switching the behavior
between a regular on-disk "git repack" and the use of pack-objects for
push/fetch (where a fetch does not want progress from the server during
the write stage; the client will print progress as it receives the
data). But there's no such distinction for bundles. Prior to
79862b6b77c, we always printed the write stage. Afterwards, a vanilla:
git bundle create foo.bundle
omits the write progress, appearing to hang (especially if your
repository is large or your disk is slow). That seems like a regression.
It's possible that the flexibility to disable the write-phase progress
_could_ be useful for bundle. E.g., if you did something like:
ssh some-host git bundle create foo.bundle |
git bundle unbundle
But if you are running both in real-time, why are you using bundles in
the first place? You're better off doing a real fetch.
But even if we did want to support that, it should be the exception, and
vanilla "bundle create" should display the full progress. So we'd want
to name the option "--no-write-progress" or something.
The "--all-progress" option itself is even worse. It exists in
pack-objects only for historical reasons. It's a mistake because it
implies "--progress", and we added "--all-progress-implied" to fix that.
There is no reason to propagate that mistake to new commands.
Likewise, the documentation for these options was pulled from
pack-objects. But it doesn't make any sense in this context. It talks
about "--stdout", but that is not even an option that git-bundle
supports.
This patch flips the default for "--all-progress-implied" back to
"true", fixing the regression in 79862b6b77c. This turns that option
into a noop, and means that "--all-progress" is really the same as
"--progress". We _could_ drop them completely, but since they've been
shipped with Git since v2.25.0, it's polite to continue accepting them.
I didn't implement any sort of "--no-write-progress" here. I'm not at
all convinced it's necessary, and the discussion from the original
thread:
https://lore.kernel.org/git/20191110204126.30553-2-robbat2@gentoo.org/
shows that that the main focus was on getting --progress and --quiet
support, and not any kind of clever "real-time bundle over the network"
feature. But technically this patch is making it impossible to do
something that you _could_ do post-79862b6b77c.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:55:13 +01:00
|
|
|
int all_progress_implied = 1;
|
2019-11-10 21:41:25 +01:00
|
|
|
int progress = isatty(STDERR_FILENO);
|
2020-07-28 22:24:27 +02:00
|
|
|
struct strvec pack_opts;
|
2020-07-30 01:14:20 +02:00
|
|
|
int version = -1;
|
2021-07-02 11:57:30 +02:00
|
|
|
int ret;
|
2019-11-10 21:41:24 +01:00
|
|
|
struct option options[] = {
|
2019-11-10 21:41:25 +01:00
|
|
|
OPT_SET_INT('q', "quiet", &progress,
|
|
|
|
N_("do not show progress meter"), 0),
|
|
|
|
OPT_SET_INT(0, "progress", &progress,
|
|
|
|
N_("show progress meter"), 1),
|
bundle: turn on --all-progress-implied by default
In 79862b6b77c (bundle-create: progress output control, 2019-11-10),
"bundle create" learned about the --all-progress and
--all-progress-implied options, which were copied from pack-objects.
I think these were a mistake.
In pack-objects, "all-progress-implied" is about switching the behavior
between a regular on-disk "git repack" and the use of pack-objects for
push/fetch (where a fetch does not want progress from the server during
the write stage; the client will print progress as it receives the
data). But there's no such distinction for bundles. Prior to
79862b6b77c, we always printed the write stage. Afterwards, a vanilla:
git bundle create foo.bundle
omits the write progress, appearing to hang (especially if your
repository is large or your disk is slow). That seems like a regression.
It's possible that the flexibility to disable the write-phase progress
_could_ be useful for bundle. E.g., if you did something like:
ssh some-host git bundle create foo.bundle |
git bundle unbundle
But if you are running both in real-time, why are you using bundles in
the first place? You're better off doing a real fetch.
But even if we did want to support that, it should be the exception, and
vanilla "bundle create" should display the full progress. So we'd want
to name the option "--no-write-progress" or something.
The "--all-progress" option itself is even worse. It exists in
pack-objects only for historical reasons. It's a mistake because it
implies "--progress", and we added "--all-progress-implied" to fix that.
There is no reason to propagate that mistake to new commands.
Likewise, the documentation for these options was pulled from
pack-objects. But it doesn't make any sense in this context. It talks
about "--stdout", but that is not even an option that git-bundle
supports.
This patch flips the default for "--all-progress-implied" back to
"true", fixing the regression in 79862b6b77c. This turns that option
into a noop, and means that "--all-progress" is really the same as
"--progress". We _could_ drop them completely, but since they've been
shipped with Git since v2.25.0, it's polite to continue accepting them.
I didn't implement any sort of "--no-write-progress" here. I'm not at
all convinced it's necessary, and the discussion from the original
thread:
https://lore.kernel.org/git/20191110204126.30553-2-robbat2@gentoo.org/
shows that that the main focus was on getting --progress and --quiet
support, and not any kind of clever "real-time bundle over the network"
feature. But technically this patch is making it impossible to do
something that you _could_ do post-79862b6b77c.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:55:13 +01:00
|
|
|
OPT_SET_INT_F(0, "all-progress", &progress,
|
|
|
|
N_("historical; same as --progress"), 2,
|
|
|
|
PARSE_OPT_HIDDEN),
|
|
|
|
OPT_HIDDEN_BOOL(0, "all-progress-implied",
|
|
|
|
&all_progress_implied,
|
|
|
|
N_("historical; does nothing")),
|
2020-07-30 01:14:20 +02:00
|
|
|
OPT_INTEGER(0, "version", &version,
|
|
|
|
N_("specify bundle format version")),
|
2019-11-10 21:41:24 +01:00
|
|
|
OPT_END()
|
|
|
|
};
|
2021-07-02 11:57:30 +02:00
|
|
|
char *bundle_file;
|
2019-11-10 21:41:24 +01:00
|
|
|
|
|
|
|
argc = parse_options_cmd_bundle(argc, argv, prefix,
|
|
|
|
builtin_bundle_create_usage, options, &bundle_file);
|
|
|
|
/* bundle internals use argv[1] as further parameters */
|
|
|
|
|
2020-07-28 22:24:27 +02:00
|
|
|
strvec_init(&pack_opts);
|
2019-11-10 21:41:25 +01:00
|
|
|
if (progress == 0)
|
2020-07-28 22:24:27 +02:00
|
|
|
strvec_push(&pack_opts, "--quiet");
|
2019-11-10 21:41:25 +01:00
|
|
|
else if (progress == 1)
|
2020-07-28 22:24:27 +02:00
|
|
|
strvec_push(&pack_opts, "--progress");
|
2019-11-10 21:41:25 +01:00
|
|
|
else if (progress == 2)
|
2020-07-28 22:24:27 +02:00
|
|
|
strvec_push(&pack_opts, "--all-progress");
|
2019-11-10 21:41:25 +01:00
|
|
|
if (progress && all_progress_implied)
|
2020-07-28 22:24:27 +02:00
|
|
|
strvec_push(&pack_opts, "--all-progress-implied");
|
2019-11-10 21:41:25 +01:00
|
|
|
|
2019-11-10 21:41:24 +01:00
|
|
|
if (!startup_info->have_repository)
|
|
|
|
die(_("Need a repository to create a bundle."));
|
2021-07-02 11:57:30 +02:00
|
|
|
ret = !!create_bundle(the_repository, bundle_file, argc, argv, &pack_opts, version);
|
2022-03-04 19:32:09 +01:00
|
|
|
strvec_clear(&pack_opts);
|
2021-07-02 11:57:30 +02:00
|
|
|
free(bundle_file);
|
|
|
|
return ret;
|
2019-11-10 21:41:24 +01:00
|
|
|
}
|
|
|
|
|
bundle: let "-" mean stdin for reading operations
For writing, "bundle create -" indicates that the bundle should be
written to stdout. But there's no matching handling of "-" for reading
operations. This is inconsistent, and a little inflexible (though one
can always use "/dev/stdin" on systems that support it).
However, it's easy to change. Once upon a time, the bundle-reading code
required a seekable descriptor, but that was fixed long ago in
e9ee84cf28b (bundle: allowing to read from an unseekable fd,
2011-10-13). So we just need to handle "-" explicitly when opening the
file.
We _could_ do this by handling "-" in read_bundle_header(), which the
reading functions all call already. But that is probably a bad idea.
It's also used by low-level code like the transport functions, and we
may want to be more careful there. We do not know that stdin is even
available to us, and certainly we would not want to get confused by a
configured URL that happens to point to "-".
So instead, let's add a helper to builtin/bundle.c. Since both the
bundle code and some of the callers refer to the bundle by name for
error messages, let's use the string "<stdin>" to make the output a bit
nicer to read.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:26:14 +01:00
|
|
|
/*
|
|
|
|
* Similar to read_bundle_header(), but handle "-" as stdin.
|
|
|
|
*/
|
|
|
|
static int open_bundle(const char *path, struct bundle_header *header,
|
|
|
|
const char **name)
|
|
|
|
{
|
|
|
|
if (!strcmp(path, "-")) {
|
|
|
|
if (name)
|
|
|
|
*name = "<stdin>";
|
|
|
|
return read_bundle_header_fd(0, header, "<stdin>");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (name)
|
|
|
|
*name = path;
|
|
|
|
return read_bundle_header(path, header);
|
|
|
|
}
|
|
|
|
|
2019-11-10 21:41:24 +01:00
|
|
|
static int cmd_bundle_verify(int argc, const char **argv, const char *prefix) {
|
bundle: remove "ref_list" in favor of string-list.c API
Move away from the "struct ref_list" in bundle.c in favor of the
almost identical string-list.c API.
That API fits this use-case perfectly, but did not exist in its
current form when this code was added in 2e0afafebd (Add git-bundle:
move objects and references by archive, 2007-02-22), with hindsight we
could have used the path-list API, which later got renamed to
string-list. See 8fd2cb4069 (Extract helper bits from
c-merge-recursive work, 2006-07-25)
We need to change "name" to "string" and "oid" to "util" to make this
conversion, but other than that the APIs are pretty much identical for
what bundle.c made use of.
Let's also replace the memset(..,0,...) pattern with a more idiomatic
"INIT" macro, and finally add a *_release() function so to free the
allocated memory.
Before this the add_to_ref_list() would leak memory, now e.g. "bundle
list-heads" reports no memory leaks at all under valgrind.
In the bundle_header_init() function we're using a clever trick to
memcpy() what we'd get from the corresponding
BUNDLE_HEADER_INIT. There is a concurrent series to make use of that
pattern more generally, see [1].
1. https://lore.kernel.org/git/cover-0.5-00000000000-20210701T104855Z-avarab@gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-02 11:57:32 +02:00
|
|
|
struct bundle_header header = BUNDLE_HEADER_INIT;
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:59:14 +01:00
|
|
|
int bundle_fd = -1;
|
2019-11-10 21:41:26 +01:00
|
|
|
int quiet = 0;
|
2021-07-02 11:57:30 +02:00
|
|
|
int ret;
|
2019-11-10 21:41:24 +01:00
|
|
|
struct option options[] = {
|
2019-11-10 21:41:26 +01:00
|
|
|
OPT_BOOL('q', "quiet", &quiet,
|
|
|
|
N_("do not show bundle details")),
|
2019-11-10 21:41:24 +01:00
|
|
|
OPT_END()
|
|
|
|
};
|
2021-07-02 11:57:30 +02:00
|
|
|
char *bundle_file;
|
bundle: let "-" mean stdin for reading operations
For writing, "bundle create -" indicates that the bundle should be
written to stdout. But there's no matching handling of "-" for reading
operations. This is inconsistent, and a little inflexible (though one
can always use "/dev/stdin" on systems that support it).
However, it's easy to change. Once upon a time, the bundle-reading code
required a seekable descriptor, but that was fixed long ago in
e9ee84cf28b (bundle: allowing to read from an unseekable fd,
2011-10-13). So we just need to handle "-" explicitly when opening the
file.
We _could_ do this by handling "-" in read_bundle_header(), which the
reading functions all call already. But that is probably a bad idea.
It's also used by low-level code like the transport functions, and we
may want to be more careful there. We do not know that stdin is even
available to us, and certainly we would not want to get confused by a
configured URL that happens to point to "-".
So instead, let's add a helper to builtin/bundle.c. Since both the
bundle code and some of the callers refer to the bundle by name for
error messages, let's use the string "<stdin>" to make the output a bit
nicer to read.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:26:14 +01:00
|
|
|
const char *name;
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:59:14 +01:00
|
|
|
|
2019-11-10 21:41:24 +01:00
|
|
|
argc = parse_options_cmd_bundle(argc, argv, prefix,
|
|
|
|
builtin_bundle_verify_usage, options, &bundle_file);
|
|
|
|
/* bundle internals use argv[1] as further parameters */
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:59:14 +01:00
|
|
|
|
bundle: let "-" mean stdin for reading operations
For writing, "bundle create -" indicates that the bundle should be
written to stdout. But there's no matching handling of "-" for reading
operations. This is inconsistent, and a little inflexible (though one
can always use "/dev/stdin" on systems that support it).
However, it's easy to change. Once upon a time, the bundle-reading code
required a seekable descriptor, but that was fixed long ago in
e9ee84cf28b (bundle: allowing to read from an unseekable fd,
2011-10-13). So we just need to handle "-" explicitly when opening the
file.
We _could_ do this by handling "-" in read_bundle_header(), which the
reading functions all call already. But that is probably a bad idea.
It's also used by low-level code like the transport functions, and we
may want to be more careful there. We do not know that stdin is even
available to us, and certainly we would not want to get confused by a
configured URL that happens to point to "-".
So instead, let's add a helper to builtin/bundle.c. Since both the
bundle code and some of the callers refer to the bundle by name for
error messages, let's use the string "<stdin>" to make the output a bit
nicer to read.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:26:14 +01:00
|
|
|
if ((bundle_fd = open_bundle(bundle_file, &header, &name)) < 0) {
|
2021-07-02 11:57:30 +02:00
|
|
|
ret = 1;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2019-11-10 21:41:24 +01:00
|
|
|
close(bundle_fd);
|
2022-10-12 14:52:37 +02:00
|
|
|
if (verify_bundle(the_repository, &header,
|
2022-10-12 14:52:38 +02:00
|
|
|
quiet ? VERIFY_BUNDLE_QUIET : VERIFY_BUNDLE_VERBOSE)) {
|
2021-07-02 11:57:30 +02:00
|
|
|
ret = 1;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
bundle: let "-" mean stdin for reading operations
For writing, "bundle create -" indicates that the bundle should be
written to stdout. But there's no matching handling of "-" for reading
operations. This is inconsistent, and a little inflexible (though one
can always use "/dev/stdin" on systems that support it).
However, it's easy to change. Once upon a time, the bundle-reading code
required a seekable descriptor, but that was fixed long ago in
e9ee84cf28b (bundle: allowing to read from an unseekable fd,
2011-10-13). So we just need to handle "-" explicitly when opening the
file.
We _could_ do this by handling "-" in read_bundle_header(), which the
reading functions all call already. But that is probably a bad idea.
It's also used by low-level code like the transport functions, and we
may want to be more careful there. We do not know that stdin is even
available to us, and certainly we would not want to get confused by a
configured URL that happens to point to "-".
So instead, let's add a helper to builtin/bundle.c. Since both the
bundle code and some of the callers refer to the bundle by name for
error messages, let's use the string "<stdin>" to make the output a bit
nicer to read.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:26:14 +01:00
|
|
|
fprintf(stderr, _("%s is okay\n"), name);
|
2021-07-02 11:57:30 +02:00
|
|
|
ret = 0;
|
|
|
|
cleanup:
|
|
|
|
free(bundle_file);
|
bundle: remove "ref_list" in favor of string-list.c API
Move away from the "struct ref_list" in bundle.c in favor of the
almost identical string-list.c API.
That API fits this use-case perfectly, but did not exist in its
current form when this code was added in 2e0afafebd (Add git-bundle:
move objects and references by archive, 2007-02-22), with hindsight we
could have used the path-list API, which later got renamed to
string-list. See 8fd2cb4069 (Extract helper bits from
c-merge-recursive work, 2006-07-25)
We need to change "name" to "string" and "oid" to "util" to make this
conversion, but other than that the APIs are pretty much identical for
what bundle.c made use of.
Let's also replace the memset(..,0,...) pattern with a more idiomatic
"INIT" macro, and finally add a *_release() function so to free the
allocated memory.
Before this the add_to_ref_list() would leak memory, now e.g. "bundle
list-heads" reports no memory leaks at all under valgrind.
In the bundle_header_init() function we're using a clever trick to
memcpy() what we'd get from the corresponding
BUNDLE_HEADER_INIT. There is a concurrent series to make use of that
pattern more generally, see [1].
1. https://lore.kernel.org/git/cover-0.5-00000000000-20210701T104855Z-avarab@gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-02 11:57:32 +02:00
|
|
|
bundle_header_release(&header);
|
2021-07-02 11:57:30 +02:00
|
|
|
return ret;
|
2019-11-10 21:41:24 +01:00
|
|
|
}
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:59:14 +01:00
|
|
|
|
2019-11-10 21:41:24 +01:00
|
|
|
static int cmd_bundle_list_heads(int argc, const char **argv, const char *prefix) {
|
bundle: remove "ref_list" in favor of string-list.c API
Move away from the "struct ref_list" in bundle.c in favor of the
almost identical string-list.c API.
That API fits this use-case perfectly, but did not exist in its
current form when this code was added in 2e0afafebd (Add git-bundle:
move objects and references by archive, 2007-02-22), with hindsight we
could have used the path-list API, which later got renamed to
string-list. See 8fd2cb4069 (Extract helper bits from
c-merge-recursive work, 2006-07-25)
We need to change "name" to "string" and "oid" to "util" to make this
conversion, but other than that the APIs are pretty much identical for
what bundle.c made use of.
Let's also replace the memset(..,0,...) pattern with a more idiomatic
"INIT" macro, and finally add a *_release() function so to free the
allocated memory.
Before this the add_to_ref_list() would leak memory, now e.g. "bundle
list-heads" reports no memory leaks at all under valgrind.
In the bundle_header_init() function we're using a clever trick to
memcpy() what we'd get from the corresponding
BUNDLE_HEADER_INIT. There is a concurrent series to make use of that
pattern more generally, see [1].
1. https://lore.kernel.org/git/cover-0.5-00000000000-20210701T104855Z-avarab@gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-02 11:57:32 +02:00
|
|
|
struct bundle_header header = BUNDLE_HEADER_INIT;
|
2019-11-10 21:41:24 +01:00
|
|
|
int bundle_fd = -1;
|
2021-07-02 11:57:30 +02:00
|
|
|
int ret;
|
2019-11-10 21:41:24 +01:00
|
|
|
struct option options[] = {
|
|
|
|
OPT_END()
|
|
|
|
};
|
2021-07-02 11:57:30 +02:00
|
|
|
char *bundle_file;
|
2019-11-10 21:41:24 +01:00
|
|
|
|
|
|
|
argc = parse_options_cmd_bundle(argc, argv, prefix,
|
|
|
|
builtin_bundle_list_heads_usage, options, &bundle_file);
|
|
|
|
/* bundle internals use argv[1] as further parameters */
|
|
|
|
|
bundle: let "-" mean stdin for reading operations
For writing, "bundle create -" indicates that the bundle should be
written to stdout. But there's no matching handling of "-" for reading
operations. This is inconsistent, and a little inflexible (though one
can always use "/dev/stdin" on systems that support it).
However, it's easy to change. Once upon a time, the bundle-reading code
required a seekable descriptor, but that was fixed long ago in
e9ee84cf28b (bundle: allowing to read from an unseekable fd,
2011-10-13). So we just need to handle "-" explicitly when opening the
file.
We _could_ do this by handling "-" in read_bundle_header(), which the
reading functions all call already. But that is probably a bad idea.
It's also used by low-level code like the transport functions, and we
may want to be more careful there. We do not know that stdin is even
available to us, and certainly we would not want to get confused by a
configured URL that happens to point to "-".
So instead, let's add a helper to builtin/bundle.c. Since both the
bundle code and some of the callers refer to the bundle by name for
error messages, let's use the string "<stdin>" to make the output a bit
nicer to read.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:26:14 +01:00
|
|
|
if ((bundle_fd = open_bundle(bundle_file, &header, NULL)) < 0) {
|
2021-07-02 11:57:30 +02:00
|
|
|
ret = 1;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2019-11-10 21:41:24 +01:00
|
|
|
close(bundle_fd);
|
2021-07-02 11:57:30 +02:00
|
|
|
ret = !!list_bundle_refs(&header, argc, argv);
|
|
|
|
cleanup:
|
|
|
|
free(bundle_file);
|
bundle: remove "ref_list" in favor of string-list.c API
Move away from the "struct ref_list" in bundle.c in favor of the
almost identical string-list.c API.
That API fits this use-case perfectly, but did not exist in its
current form when this code was added in 2e0afafebd (Add git-bundle:
move objects and references by archive, 2007-02-22), with hindsight we
could have used the path-list API, which later got renamed to
string-list. See 8fd2cb4069 (Extract helper bits from
c-merge-recursive work, 2006-07-25)
We need to change "name" to "string" and "oid" to "util" to make this
conversion, but other than that the APIs are pretty much identical for
what bundle.c made use of.
Let's also replace the memset(..,0,...) pattern with a more idiomatic
"INIT" macro, and finally add a *_release() function so to free the
allocated memory.
Before this the add_to_ref_list() would leak memory, now e.g. "bundle
list-heads" reports no memory leaks at all under valgrind.
In the bundle_header_init() function we're using a clever trick to
memcpy() what we'd get from the corresponding
BUNDLE_HEADER_INIT. There is a concurrent series to make use of that
pattern more generally, see [1].
1. https://lore.kernel.org/git/cover-0.5-00000000000-20210701T104855Z-avarab@gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-02 11:57:32 +02:00
|
|
|
bundle_header_release(&header);
|
2021-07-02 11:57:30 +02:00
|
|
|
return ret;
|
2019-11-10 21:41:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
static int cmd_bundle_unbundle(int argc, const char **argv, const char *prefix) {
|
bundle: remove "ref_list" in favor of string-list.c API
Move away from the "struct ref_list" in bundle.c in favor of the
almost identical string-list.c API.
That API fits this use-case perfectly, but did not exist in its
current form when this code was added in 2e0afafebd (Add git-bundle:
move objects and references by archive, 2007-02-22), with hindsight we
could have used the path-list API, which later got renamed to
string-list. See 8fd2cb4069 (Extract helper bits from
c-merge-recursive work, 2006-07-25)
We need to change "name" to "string" and "oid" to "util" to make this
conversion, but other than that the APIs are pretty much identical for
what bundle.c made use of.
Let's also replace the memset(..,0,...) pattern with a more idiomatic
"INIT" macro, and finally add a *_release() function so to free the
allocated memory.
Before this the add_to_ref_list() would leak memory, now e.g. "bundle
list-heads" reports no memory leaks at all under valgrind.
In the bundle_header_init() function we're using a clever trick to
memcpy() what we'd get from the corresponding
BUNDLE_HEADER_INIT. There is a concurrent series to make use of that
pattern more generally, see [1].
1. https://lore.kernel.org/git/cover-0.5-00000000000-20210701T104855Z-avarab@gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-02 11:57:32 +02:00
|
|
|
struct bundle_header header = BUNDLE_HEADER_INIT;
|
2019-11-10 21:41:24 +01:00
|
|
|
int bundle_fd = -1;
|
2021-07-02 11:57:30 +02:00
|
|
|
int ret;
|
bundle: show progress on "unbundle"
The "unbundle" command added in 2e0afafebd8 (Add git-bundle: move
objects and references by archive, 2007-02-22) did not show progress
output, even though the underlying API learned how to show progress in
be042aff24c (Teach progress eye-candy to fetch_refs_from_bundle(),
2011-09-18).
Now we'll show "Unbundling objects" using the new --progress-title
option to "git index-pack", to go with its existing "Receiving
objects" and "Indexing objects" (which it shows when invoked with
"--stdin", and with a pack file, respectively).
Unlike "git bundle create" we don't handle "--quiet" here, nor
"--all-progress" and "--all-progress-implied". Those are all specific
to "create" (and "verify", in the case of "--quiet").
The structure of the existing documentation is a bit unclear, e.g. the
documentation for the "--quiet" option added in
79862b6b77c (bundle-create: progress output control, 2019-11-10) only
describes how it works for "create", and not for "verify". That and
other issues in it should be fixed, but I'd like to avoid untangling
that mess right now. Let's just support the standard "--no-progress"
implicitly here, and leave cleaning up the general behavior of "git
bundle" for a later change.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-05 09:34:45 +02:00
|
|
|
int progress = isatty(2);
|
|
|
|
|
2019-11-10 21:41:24 +01:00
|
|
|
struct option options[] = {
|
bundle: show progress on "unbundle"
The "unbundle" command added in 2e0afafebd8 (Add git-bundle: move
objects and references by archive, 2007-02-22) did not show progress
output, even though the underlying API learned how to show progress in
be042aff24c (Teach progress eye-candy to fetch_refs_from_bundle(),
2011-09-18).
Now we'll show "Unbundling objects" using the new --progress-title
option to "git index-pack", to go with its existing "Receiving
objects" and "Indexing objects" (which it shows when invoked with
"--stdin", and with a pack file, respectively).
Unlike "git bundle create" we don't handle "--quiet" here, nor
"--all-progress" and "--all-progress-implied". Those are all specific
to "create" (and "verify", in the case of "--quiet").
The structure of the existing documentation is a bit unclear, e.g. the
documentation for the "--quiet" option added in
79862b6b77c (bundle-create: progress output control, 2019-11-10) only
describes how it works for "create", and not for "verify". That and
other issues in it should be fixed, but I'd like to avoid untangling
that mess right now. Let's just support the standard "--no-progress"
implicitly here, and leave cleaning up the general behavior of "git
bundle" for a later change.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-05 09:34:45 +02:00
|
|
|
OPT_BOOL(0, "progress", &progress,
|
|
|
|
N_("show progress meter")),
|
2019-11-10 21:41:24 +01:00
|
|
|
OPT_END()
|
|
|
|
};
|
2021-07-02 11:57:30 +02:00
|
|
|
char *bundle_file;
|
2021-09-05 09:34:43 +02:00
|
|
|
struct strvec extra_index_pack_args = STRVEC_INIT;
|
2019-11-10 21:41:24 +01:00
|
|
|
|
|
|
|
argc = parse_options_cmd_bundle(argc, argv, prefix,
|
|
|
|
builtin_bundle_unbundle_usage, options, &bundle_file);
|
|
|
|
/* bundle internals use argv[1] as further parameters */
|
|
|
|
|
bundle: let "-" mean stdin for reading operations
For writing, "bundle create -" indicates that the bundle should be
written to stdout. But there's no matching handling of "-" for reading
operations. This is inconsistent, and a little inflexible (though one
can always use "/dev/stdin" on systems that support it).
However, it's easy to change. Once upon a time, the bundle-reading code
required a seekable descriptor, but that was fixed long ago in
e9ee84cf28b (bundle: allowing to read from an unseekable fd,
2011-10-13). So we just need to handle "-" explicitly when opening the
file.
We _could_ do this by handling "-" in read_bundle_header(), which the
reading functions all call already. But that is probably a bad idea.
It's also used by low-level code like the transport functions, and we
may want to be more careful there. We do not know that stdin is even
available to us, and certainly we would not want to get confused by a
configured URL that happens to point to "-".
So instead, let's add a helper to builtin/bundle.c. Since both the
bundle code and some of the callers refer to the bundle by name for
error messages, let's use the string "<stdin>" to make the output a bit
nicer to read.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-04 11:26:14 +01:00
|
|
|
if ((bundle_fd = open_bundle(bundle_file, &header, NULL)) < 0) {
|
2021-07-02 11:57:30 +02:00
|
|
|
ret = 1;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
2019-11-10 21:41:24 +01:00
|
|
|
if (!startup_info->have_repository)
|
|
|
|
die(_("Need a repository to unbundle."));
|
bundle: show progress on "unbundle"
The "unbundle" command added in 2e0afafebd8 (Add git-bundle: move
objects and references by archive, 2007-02-22) did not show progress
output, even though the underlying API learned how to show progress in
be042aff24c (Teach progress eye-candy to fetch_refs_from_bundle(),
2011-09-18).
Now we'll show "Unbundling objects" using the new --progress-title
option to "git index-pack", to go with its existing "Receiving
objects" and "Indexing objects" (which it shows when invoked with
"--stdin", and with a pack file, respectively).
Unlike "git bundle create" we don't handle "--quiet" here, nor
"--all-progress" and "--all-progress-implied". Those are all specific
to "create" (and "verify", in the case of "--quiet").
The structure of the existing documentation is a bit unclear, e.g. the
documentation for the "--quiet" option added in
79862b6b77c (bundle-create: progress output control, 2019-11-10) only
describes how it works for "create", and not for "verify". That and
other issues in it should be fixed, but I'd like to avoid untangling
that mess right now. Let's just support the standard "--no-progress"
implicitly here, and leave cleaning up the general behavior of "git
bundle" for a later change.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-05 09:34:45 +02:00
|
|
|
if (progress)
|
|
|
|
strvec_pushl(&extra_index_pack_args, "-v", "--progress-title",
|
|
|
|
_("Unbundling objects"), NULL);
|
2021-09-05 09:34:43 +02:00
|
|
|
ret = !!unbundle(the_repository, &header, bundle_fd,
|
2022-10-12 14:52:37 +02:00
|
|
|
&extra_index_pack_args, 0) ||
|
2019-11-10 21:41:24 +01:00
|
|
|
list_bundle_refs(&header, argc, argv);
|
bundle: remove "ref_list" in favor of string-list.c API
Move away from the "struct ref_list" in bundle.c in favor of the
almost identical string-list.c API.
That API fits this use-case perfectly, but did not exist in its
current form when this code was added in 2e0afafebd (Add git-bundle:
move objects and references by archive, 2007-02-22), with hindsight we
could have used the path-list API, which later got renamed to
string-list. See 8fd2cb4069 (Extract helper bits from
c-merge-recursive work, 2006-07-25)
We need to change "name" to "string" and "oid" to "util" to make this
conversion, but other than that the APIs are pretty much identical for
what bundle.c made use of.
Let's also replace the memset(..,0,...) pattern with a more idiomatic
"INIT" macro, and finally add a *_release() function so to free the
allocated memory.
Before this the add_to_ref_list() would leak memory, now e.g. "bundle
list-heads" reports no memory leaks at all under valgrind.
In the bundle_header_init() function we're using a clever trick to
memcpy() what we'd get from the corresponding
BUNDLE_HEADER_INIT. There is a concurrent series to make use of that
pattern more generally, see [1].
1. https://lore.kernel.org/git/cover-0.5-00000000000-20210701T104855Z-avarab@gmail.com/
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-07-02 11:57:32 +02:00
|
|
|
bundle_header_release(&header);
|
2021-07-02 11:57:30 +02:00
|
|
|
cleanup:
|
|
|
|
free(bundle_file);
|
|
|
|
return ret;
|
2019-11-10 21:41:24 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int cmd_bundle(int argc, const char **argv, const char *prefix)
|
|
|
|
{
|
2022-08-19 18:04:01 +02:00
|
|
|
parse_opt_subcommand_fn *fn = NULL;
|
2019-11-10 21:41:24 +01:00
|
|
|
struct option options[] = {
|
2022-08-19 18:04:01 +02:00
|
|
|
OPT_SUBCOMMAND("create", &fn, cmd_bundle_create),
|
|
|
|
OPT_SUBCOMMAND("verify", &fn, cmd_bundle_verify),
|
|
|
|
OPT_SUBCOMMAND("list-heads", &fn, cmd_bundle_list_heads),
|
|
|
|
OPT_SUBCOMMAND("unbundle", &fn, cmd_bundle_unbundle),
|
2019-11-10 21:41:24 +01:00
|
|
|
OPT_END()
|
|
|
|
};
|
|
|
|
|
|
|
|
argc = parse_options(argc, argv, prefix, options, builtin_bundle_usage,
|
2022-08-19 18:04:01 +02:00
|
|
|
0);
|
2019-11-10 21:41:24 +01:00
|
|
|
|
|
|
|
packet_trace_identity("bundle");
|
|
|
|
|
2022-08-19 18:04:01 +02:00
|
|
|
return !!fn(argc, argv, prefix);
|
Add git-bundle: move objects and references by archive
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-22 01:59:14 +01:00
|
|
|
}
|