completion: add file completion tests

The commit fea16b4 (git-completion.bash: add support for path
completion) introduced quite a few changes, without the usual tests.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: document tilde expansion failure in tests

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion; remove unuseful comments

The only caller, __git_complete_index_file() doesn't specify any limits
to the options for 'git ls-files', neither should this function.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: use __gitcompadd for __gitcomp_file

Like the rest of the script does; let's not access COMPREPLY directly.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: refactor diff_index wrappers

At the end of the day what we really need is to find out the files that
have been staged, or modified, because those files are the ones that
make sense to pass as arguments to 'git commit'.

We need diff-index to find those out, since 'git ls-files' doesn't do
that.

But we don't need wrappers and wrappers basically identical to the ones
used for 'git ls-files', when we can pretend it receives a --committable
option that would return what we need.

That way, we can remove a bunch of code without any functional changes.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: refactor __git_complete_index_file()

The calls to __gitcomp_file() are essentially the same, but with
different prefix.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: add hack to enable file mode in bash < 4

This way we don't need all the compat stuff, different filters, and so
on. Also, now we complete exactly the same in bash 3 and bash 4.

This is the way bash-completion did it for quite some time, when bash 3
was supported. For more information about the hack:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=272660#64

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: add space after completed filename

Just like before fea16b4 (git-completion.bash: add support for path
completion).

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: remove __git_index_file_list_filter()

Refactor the code into the only caller; __git_index_files().

Also, Somehow messing up with the 'path' variable messes up the 'PATH'
variable. So let's not do that.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-export: do not parse non-commit objects while reading marks file

We read from the marks file and keep only marked commits, but in
order to find the type of object, we are parsing the whole thing,
which is slow, specially in big repositories with lots of big files.

There's no need for that, we can query the object information with
sha1_object_info().

Before this, loading the objects of a fresh emacs import, with 260598
blobs took 14 minutes, after this patch, it takes 3 seconds.

This is the way fast-import does it. Also die if the object is not
found (like fast-import).

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-export: don't parse commits while reading marks file

We don't need the parsed objects at this point, merely the
information that they have marks.

Seems to be three times faster in my setup with lots of objects.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
clone: allow cloning local paths with colons in them

Usually "foo:bar" is interpreted as an ssh url. This patch allows to
clone from such paths by putting at least one slash before the colon
(i.e. /path/to/foo:bar or just ./foo:bar).

file://foo:bar should also work, but local optimizations are off in
that case, which may be unwanted. While at there, warn the users about
--local being ignored in this case.

Reported-by: William Giokas <1007380@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-{import,export}: use get_sha1_hex() to read from marks file

It's wrong to call get_sha1() if they should be SHA-1s, plus
inefficient.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: cleanup zsh wrapper

There's no need for a separate function; we can call
'emulate -k ksh func'.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: synchronize zsh wrapper

So it's closer to the full zsh wrapper.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
help: add help_unknown_ref()

When the user gives an unknown string to a command that expects to
get a ref, we could be more helpful than just saying "that's not a
ref" and die.

Add helper function help_unknown_ref() to take care of displaying an
error message along with a list of suggested refs the user might
have meant.  An interaction with "git merge" might go like this:

	$ git merge foo
	merge: foo - not something we can merge

	Did you mean one of these?
	    origin/foo
	    upstream/foo

Signed-off-by: Vikrant Varma <vikrant.varma94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge: use help_unknown_ref()

Use help.c:help_unknown_ref() instead of die() to provide a
friendlier error message before exiting, when one of the refs
specified in a merge is unknown.

Signed-off-by: Vikrant Varma <vikrant.varma94@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5004: avoid using tar for checking emptiness of archive

Test 2 of t5004 checks if a supposedly empty tar archive really
contains no files.  24676f02 (t5004: fix issue with empty archive test
and bsdtar) removed our commit hash to make it work with bsdtar, but
the test still fails on NetBSD and OpenBSD, which use their own tar
that considers a tar file containing only NULs as broken.

Here's what the different archivers do when asked to create a tar
file without entries:

	$ uname -v
	NetBSD 6.0.1 (GENERIC)
	$ gtar --version | head -1
	tar (GNU tar) 1.26
	$ bsdtar --version
	bsdtar 2.8.4 - libarchive 2.8.4

	$ : >zero.tar
	$ perl -e 'print "\0" x 10240' >tenk.tar
	$ sha1 zero.tar tenk.tar
	SHA1 (zero.tar) = da39a3ee5e6b4b0d3255bfef95601890afd80709
	SHA1 (tenk.tar) = 34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c

	$ : | tar cf - -T - | sha1
	da39a3ee5e6b4b0d3255bfef95601890afd80709
	$ : | gtar cf - -T - | sha1
	34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c
	$ : | bsdtar cf - -T - | sha1
	34e163be8e43c5631d8b92e9c43ab0bf0fa62b9c

So NetBSD's native tar creates an empty file, while GNU tar and bsdtar
both give us 10KB of NULs -- just like git archive with an empty tree.
Now let's see how the archivers handle these two kinds of empty tar
files:

	$ tar tf zero.tar; echo $?
	tar: Unexpected EOF on archive file
	1
	$ gtar tf zero.tar; echo $?
	gtar: This does not look like a tar archive
	gtar: Exiting with failure status due to previous errors
	2
	$ bsdtar tf zero.tar; echo $?
	0

	$ tar tf tenk.tar; echo $?
	tar: Cannot identify format. Searching...
	tar: End of archive volume 1 reached
	tar: Sorry, unable to determine archive format.
	$ gtar tf tenk.tar; echo $?
	0
	$ bsdtar tf tenk.tar; echo $?
	0

NetBSD's tar complains about both, bsdtar happily accepts any of them
and GNU tar doesn't like zero-length archive files.  So the safest
course of action is to stay with our block-of-NULs format which is
compatible with GNU tar and bsdtar, as we can't make NetBSD's native
tar happy anyway.

We can simplify our test, however, by taking tar out of the picture.
Instead of extracting the archive and checking for the non-presence of
files, check if the file has a size of 10KB and contains only NULs.
This makes t5004 pass on NetBSD and OpenBSD.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5004: resurrect original empty tar archive test

Add a test to verify the emptiness of an archive by extracting its
contents.  Don't run this test if the version of tar doesn't support
archives containing only a comment header, though.

The existing check 'tar archive of empty tree is empty' used to work
like that (minus the tar capability check) but was changed to depend
on the exact representation of empty tar files created by git archive
instead of on the behaviour of tar in order to avoid issues with
different tar versions.

The different approaches test different things: The existing one is
for empty trees, for which we know the exact expected output and thus
we can simply check it without extracting; the new one is for commits
with empty trees, whose archives include stamps and so the more
"natural" check by extraction is a better fit because it focuses on
the interesting aspect, namely the absence of any archive entries.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'master' into next

* master:
  Git 1.8.2.3
  cherry-pick: picking a tag that resolves to a commit is OK
  t5004: avoid using tar for checking emptiness of archive
  t5004: ignore pax global header file
  mergetools/kdiff3: do not use --auto when diffing
  transport-helper: trivial style cleanup