If make a empty git repo with git init and start the verify, now it works.
That's strange, because it would be easy to display a good error message instead of a crash.
That is very true, and what Git 2.22.1 (Q2 2019) is doing:
See commit 3bbbe46 (27 May 2019) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit abbd504, 25 Jul 2019)
bundle verify: error out if called without an object database
The deal with bundles is: they really are thin packs, with very little
sugar on top. So we really need a repository (or more appropriately, an
object database) to work with, when asked to verify a bundle.
Let's error out with a useful error message if git bundle verify is
called without such an object database to work with.
Reported by Konstantin Ryabitsev.
That means git/git bundle.c#verify_bundle() function now includes:
if (!r || !r->objects || !r->objects->odb)
return error(_("need a repository to verify a bundle"));
With Git 2.34 (Q4 2021), the "thin packs" part is clarified:
See commit 1d9c8da, commit 0bb92f3, commit 9ab80dd, commit 5c8273d (31 Jul 2021) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit f19b275, 24 Aug 2021)
bundle doc: rewrite the "DESCRIPTION" section
Signed-off-by: Ævar Arnfjörð Bjarmason
Rewrite the "DESCRIPTION" section for "git bundle"(man) to start by talking about what bundles are in general terms, rather than diving directly into one example of what they might be used for.
This changes documentation that's been substantially the same ever since the command was added in 2e0afaf ("Add git-bundle: move objects and references by archive", 2007-02-22, Git v1.5.1-rc1 -- merge).
There was a discussion about whether to say anything at all about "thin packs" here.
I think it's good to mention it for the curious reader willing to read the technical docs, but let's explicitly say that there's no "thick pack", and that the difference shouldn't matter.
git bundle now includes in its man page:
Create, unpack, and manipulate "bundle" files. Bundles are used for
the "offline" transfer of Git objects without an active "server"
sitting on the other side of the network connection.
They can be used to create both incremental and full backups of a
repository, and to relay the state of the references in one repository
to another.
Git commands that fetch or otherwise "read" via protocols such as
ssh:// and https:// can also operate on bundle files. It is
possible git clone a new repository from a bundle, to use
git fetch to fetch from one, and to list the references
contained within it with git ls-remote. There's no
corresponding "write" support, i.e.a 'git push' into a bundle is not
supported.
See the "EXAMPLES" section below for examples of how to use bundles.
BUNDLE FORMAT
Bundles are .pack files (see git pack-objects) with a
header indicating what references are contained within the bundle.
Like the the packed archive format itself bundles can either be
self-contained, or be created using exclusions.
Bundles created using revision exclusions are "thin packs" created
using the --thin option to git pack-objects, and
unbundled using the --fix-thin option to git index-pack.
There is no option to create a "thick pack" when using revision
exclusions, users should not be concerned about the difference. By
using "thin packs" bundles created using exclusions are smaller in
size. That they're "thin" under the hood is merely noted here as a
curiosity, and as a reference to other documentation
See technical/bundle-format, the bundle-format
documentation for more details and the discussion of "thin pack" in
technical/pack-format, the pack format documentation for
further details.
With Git 2.40 (Q1 2023), git bundle <subcmd> will be more resilient.
See commit 6d5e9e5, commit e778ecb (27 Dec 2022), and commit 891cb09 (20 Dec 2022) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit bc58ebf, 05 Jan 2023)
bundle: don't segfault on "git bundle "
Reported-by: Hubert Jasudowicz
Signed-off-by: Ævar Arnfjörð Bjarmason
Tested-by: Hubert Jasudowicz
Since aef7d75 ("builtin/bundle.c: let parse-options parse subcommands", 2022-08-19, Git v2.38.0-rc0 -- merge listed in batch #17) we've been segfaulting if no argument was provided.
The fix is easy, as all of the "git bundle"(man) subcommands require a non-option argument we can check that we have arguments left after calling parse-options().
This makes use of code added in 73c3253 ("bundle: framework for options before bundle file", 2019-11-10, Git v2.25.0-rc0 -- merge listed in batch #2), before this change that code has always been unreachable.
In 73c3253 we'd never reach it as we already checked "argc < 2" in cmd_bundle() itself.
Then when aef7d75 (whose segfault we're fixing here) migrated this code to the subcommand API it removed that "argc < 2" check, but we were still checking the wrong "argc" in parse_options_cmd_bundle(), we need to check the "newargc".
The "argc" will always be >= 1, as it will necessarily contain at least the subcommand name itself (e.g. "create").
As an aside, this could be safely squashed into this, but let's not do that for this minimal segfault fix, as it's an unrelated refactoring:
--- a/builtin/bundle.c
+++ b/builtin/bundle.c
@@ -55,13 +55,12 @@ static int parse_options_cmd_bundle(int argc,
const char * const usagestr[],
const struct option options[],
char **bundle_file) {
- int newargc;
- newargc = parse_options(argc, argv, NULL, options, usagestr,
+ argc = parse_options(argc, argv, NULL, options, usagestr,
PARSE_OPT_STOP_AT_NON_OPTION);
- if (!newargc)
+ if (!argc)
usage_with_options(usagestr, options);
*bundle_file = prefix_filename(prefix, argv[0]);
- return newargc;
+ return argc;
}
static int cmd_bundle_create(int argc, const char **argv, const char *prefix) {
