deprecate core.statinfo at Git 2.0 boundary

c08e4d5b5cfa (Enable minimal stat checking, 2013-01-22) advertised
the configuration variable core.checkstat in the documentation and
its log message, but the code expected core.statinfo instead.

For now, add core.checkstat, and warn people who have core.statinfo
in their configuration file that we will remove it in Git 2.0.

Noticed-by: Jeff King <peff@peff.net>
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>
t5551: do not use unportable sed '\+'

The set-up step to prepare a repository with 50000 tags used a
non-porable '\+' to match one-or-more.

The error was not caught because the next test that uses that
repository did not even bother to check if these expected tags were
actually cloned to the resulting repository.

Fix the sed construct to use BRE and update the "clone" test that
wanted to test cloning from such a repository with many refs to
check the resulting repository.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
coverage: split build target into compile and test

Confusingly, the coverage-build target in fact builds with gcov
support _and runs tests_.

Split it into two targets that actually are named after what they do.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
coverage: do not delete .gcno files before building

The coverage-compile target depends on coverage-clean, which is
supposed to remove the earlier build products that would get in the
way of the next coverage test run.

However, removing *.gcno is actively wrong.  These are the files that
contain the compile-time coverage related data.  They are only rebuilt
if the source is compiled.  So if one ran 'make coverage' two times in
a row, the second run would remove *.gcno, but then fail to recreate
them because neither source files nor build flags have changed.  (This
remained hidden for so long most likely because any other intervening
use of 'make' will change the build flags, causing a full rebuild.)

So we make an exception for *.gcno.  The *.gcda are the coverage
results, written when the gcov-instrumented program is run.  We still
remove those, so as to get a one-test-run view of the data; you could
probably argue the other way too.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
coverage: set DEFAULT_TEST_TARGET to avoid using prove

If the user sets DEFAULT_TEST_TARGET=prove in his config.mak, that
carries over into the coverage tests.  Which is really bad if he also
sets GIT_PROVE_OPTS=-j<..> as that completely breaks the coverage
runs.

Instead of attempting to mess with the GIT_PROVE_OPTS, just force the
test target to 'test' so that we run under make, like we intended all
along.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
coverage: build coverage-untested-functions by default

Change the 'coverage' target to build coverage-untested-functions by
default, so as to make it more discoverable.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/merge-options.txt: restore `-e` option

It looks like commit f8246281af9adb0fdddbcc90d2e19cb5cd5217e5
unintentionally removed the documentation for the `-e` option.

Signed-off-by: Richard Hansen <rhansen@bbn.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5000: integrate export-subst tests into regular tests

Instead of creating extra archives for testing substitutions, set the
attribute export-subst and overwrite the marked file with the expected
(expanded) content right between committing and archiving.  Thus
placeholder expansion based on the committed content is performed with
each archive creation and the comparison with the contents of directory
a yields the correct result.  We can then remove the special tests for
export-subst.

Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5000, t5003: create directories for extracted files lazily

Create the directories b and c just before they are needed instead of
up front.  For t5003 it turns out we don't need them at all.  For t5000
it makes the coming modifications easier.

Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5000: factor out check_tar

Create a helper function that extracts a tar archive and checks its
contents, modelled after check_zip in t5003.

Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5000: use check_tar for prefix test

Perform the full range of checks against all archived files instead of
looking only at the file type of a few of them.  Also add a test of a
git archive with a prefix ending in with a slash, i.e. adding a full
directory level.

Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5000: simplify tar-tree tests

Just compare the archives created by git tar-tree with the ones created
using git archive with the equivalent options, whose contents are
checked already, instead of extracting them again.

Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5000: test long filenames

Add a file with a long name to the test archive in order to check
entries with pax extended headers.  Also add a check for tar versions
that doen't understand this format.  Those versions should extract the
headers as a regular files.  Add code to check_tar() to interpret the
path header if present, so that our tests work even with those tar
versions.

It's important to use the fallback code only if needed to still be
able to detect git archive errorously creating pax headers as regular
file entries (with a suitable tar version, of course).

The archive used to check for pax header support in tar was generated
using GNU tar 1.26 and its option --format=pax.

Tested successfully on NetBSD 6.1, which has a tar version lacking pax
header support.

Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/diff-index: mention two modes of operation

"diff-index" can be used to compare a tree with the tracked working
tree files (when used without the --index option), or with the index
(when used with the --index option).

The text however did not say anything about the comparison with the
working tree at all.  Fix this.

Reported-by: Albert Netymk <albertnetymk@gmail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
contrib/git-subtree: Use /bin/sh interpreter instead of /bin/bash

Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree:
it's required for systems which don't use bash by default (for example,
FreeBSD), while there seem to be no bashisms in the script (confirmed
by looking through the source and tesing subtree functionality with
FreeBSD's /bin/sh) to require specifically bash and not the generic
posix shell.

Signed-off-by: Dmitry Marakasov <amdmi3@amdmi3.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sha1_name: fix error message for @{u}

Currently, when no (valid) upstream is configured for a branch, you get
an error like:

  $ git show @{u}
  error: No upstream configured for branch 'upstream-error'
  error: No upstream configured for branch 'upstream-error'
  fatal: ambiguous argument '@{u}': unknown revision or path not in the working tree.
  Use '--' to separate paths from revisions, like this:
  'git <command> [<revision>...] -- [<file>...]'

The "error: " line actually appears twice, and the rest of the error
message is useless.  In sha1_name.c:interpret_branch_name(), there is
really no point in processing further if @{u} couldn't be resolved, and
we might as well die() instead of returning an error().  After making
this change, you get:

  $ git show @{u}
  fatal: No upstream configured for branch 'upstream-error'

Also tweak a few tests in t1507 to expect this output.

This only turns error() that may be called after we know we are
dealing with an @{upstream} marker into die(), without touching
silent error returns "return -1" from the function.  Any caller that
wants to handle an error condition itself will not be hurt by this
change, unless they want to see the message from error() and then
exit silently without giving its own message, which needs to be
fixed anyway.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>