delta/git.git/builtin/bundle.c, branch ce/https-public-key-pinning

bundle: verify arguments more strictly

2015-05-08T17:52:11+00:00

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:21+00:00

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:57+00:00

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

Use angles for placeholders consistently

2010-10-08T19:29:52+00:00

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:33+00:00

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:41+00:00

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