git/builtin/bundle.c, branch v2.6.2

bundle: verify arguments more strictly

2015-05-08T17:52:11Z

The `verify` and `create` subcommands of the bundle builtin do not properly verify the command line arguments that have been passed in. While the `verify` subcommand accepts an arbitrary amount of ignored arguments the `create` subcommand does not complain about being passed too few arguments, resulting in a bogus call to `git rev-list`. Fix these errors by verifying that the correct amount of arguments has been passed in. Signed-off-by: Patrick Steinhardt Acked-by: Johannes Schindelin Signed-off-by: Junio C Hamano

Teach progress eye-candy to fetch_refs_from_bundle()

2011-09-19T18:07:21Z

With the usual "git" transport, a large-ish transfer with "git fetch" and "git pull" give progress eye-candy to avoid boring users. However, not when they are reading from a bundle. I.e. $ git pull ../git-bundle.bndl master This teaches bundle.c:unbundle() to give "-v" option to index-pack and tell it to give progress bar when transport decides it is necessary. The operation in the other direction, "git bundle create", could also learn to honor --quiet but that is a separate issue. Signed-off-by: Junio C Hamano

i18n: git-bundle basic messages

2011-03-10T07:52:57Z

Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

Use angles for placeholders consistently

2010-10-08T19:29:52Z

Signed-off-by: Štěpán Němec Acked-by: Jonathan Nieder Signed-off-by: Junio C Hamano

bundle: run setup_git_directory_gently() sooner

2010-08-16T02:57:33Z

Without this change, “git -p bundle” does not always respect the repository-local “[core] pager” setting. It is hard to notice because subcommands other than “git bundle unbundle” do not produce much output. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

Move 'builtin-*' into a 'builtin/' subdirectory

2010-02-22T22:29:41Z

This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano