Our rename detection is a heuristic, matching pairs of
removed and added files with similar or identical content.
It's unlikely to be wrong when there is actual content to
compare, and we already take care not to do inexact rename
detection when there is not enough content to produce good
results.

However, we always do exact rename detection, even when the
blob is tiny or empty. It's easy to get false positives with
an empty blob, simply because it is an obvious content to
use as a boilerplate (e.g., when telling git that an empty
directory is worth tracking via an empty .gitignore).

This patch lets callers specify whether or not they are
interested in using empty files as rename sources and
destinations. The default is "yes", keeping the original
behavior. It works by detecting the empty-blob sha1 for
rename sources and destinations.

One more flexible alternative would be to allow the caller
to specify a minimum size for a blob to be "interesting" for
rename detection. But that would catch small boilerplate
files, not large ones (e.g., if you had the GPL COPYING file
in many directories).

A better alternative would be to allow a "-rename"
gitattribute to allow boilerplate files to be marked as
such. I'll leave the complexity of that solution until such
time as somebody actually wants it. The complaints we've
seen so far revolve around empty files, so let's start with
the simple thing.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The read-cache implementation defines this static function,
but it is a generally useful concept in git. Let's give
the empty blob the same treatment as the empty tree,
providing both hex and binary forms of the sha1.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This macro already evaluates to the correct type, as it
casts the string literal to "unsigned char *" itself
(and callers who want the literal can use the _LITERAL
form).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:

* maint-1.7.8:
  t/Makefile: Use $(sort ...) explicitly where needed
  gitweb: Fix actionless dispatch for non-existent objects
  i18n of multi-line advice messages

* ks/sort-wildcard-in-makefile:
  t/Makefile: Use $(sort ...) explicitly where needed

* jc/advise-i18n:
  i18n of multi-line advice messages

* jn/gitweb-unspecified-action:
  gitweb: Fix actionless dispatch for non-existent objects

* ab/perl-i18n:
  perl/Makefile: install Git::I18N under NO_PERL_MAKEMAKER
  Git::I18N: compatibility with perl <5.8.3

When I added the i18n infrastructure in v1.7.8-rc2-1-g5e9637c6 I forgot
to install Git::I18N also when NO_PERL_MAKEMAKER=YesPlease was
set. Change the generation of the fallback perl.mak file to do that.

Now Git/I18N.pm is installed alongside Git.pm in such a way that
anything that uses GITPERLLIB will find it.
Reported-by: NTom G. Christensen <tgc@statsbiblioteket.dk>
Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* th/mergetools-deltawalker:
  Documentation/difftool: add deltawalker to list of valid diff tools

The code to validate the history connectivity between old refs and new
refs used by fetch and receive-pack, introduced in 1.7.8, was grossly
inefficient and unnecessarily tried to re-validate integrity of individual
objects. This essentially reverts that performance regression.

* jc/maint-verify-objects-remove-pessimism:
  fetch/receive: remove over-pessimistic connectivity check

* sl/customize-sane-tool-path:
  configure: allow user to prevent $PATH "sanitization" on Solaris

Andrew Sayers noticed that the svn-fe | git fast-import pipeline
mishandles a subversion history that copies the root directory to a
sub-directory (e.g. doing `svn cp . trunk` to standardise your
layout).  As David Barr explained, the bug arises when the following
command is sent to git fast-import:

  'ls' SP ':1' SP LF

Instead of reading back what is at the root of r1, it unconditionally
reports the path as missing.

After sleeping on it, here are two patches for 'maint'.  One plugs a
memory leak.  The other ensures that trying to pass an empty path to
the 'ls' command results in an error message that can help the
frontend author instead of the silently broken conversion Andrew
found.

Then we can carefully add 'ls ""' support in 1.7.11.

* commit 'refs/pull-request-tags/jn/maint-fast-import-empty-ls':
  fast-import: don't allow 'ls' of path with empty components
  fast-import: leakfix for 'ls' of dirty trees

* th/git-diffall:
  contrib/diffall: fix cleanup trap on Windows
  contrib/diffall: eliminate duplicate while loops
  contrib/diffall: eliminate use of tar
  contrib/diffall: create tmp dirs without mktemp
  contrib/diffall: comment actual reason for 'cdup'

* th/doc-diff-submodule-option:
  Documentation/diff-options: reword description of --submodule option

Git 1.7.8 introduced an object and history re-validation step after
"fetch" or "push" causes new history to be added to a receiving
repository. This is to protect a malicious server or pushing client from
corrupting the repository by taking advantage of an existing corrupt
object that is unconnected to existing history.

But this check is way over-pessimistic.  During "fetch" or "receive-pack"
(the server side of "push"), unpack-objects and index-pack already
validate individual objects that are received, and the only thing we would
want to catch are corrupted objects that already happen to exist in our
repository but are not referenced from our refs.  Such objects must have
been written by an earlier run of our codepaths that write out loose
objects or packfiles, and they must have done the validation of individual
objects when they did so.  The only thing left to worry about is the
connectivity integrity, which can be checked with "rev-list --objects",
which is much cheaper.  We have been paying the 5x to 8x runtime overhead
the --verify-objects often adds for no real gain.

Revert check_everything_connected() not to use this over-pessimistic
check.

Credit goes to Nguyễn Thái Ngọc Duy, who originally identified the
performance regression and endured multiple rounds of reviews to fix it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

deltawalker has been supported since 284a126c, but was not added
to the list of valid diff tools reported by 'git difftool --help'.
Signed-off-by: NTim Henigan <tim.henigan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Prior to this commit, the cleanup trap that removes the tmp dir
created by the script would fail on Windows. The error was silently
ignored by the script.

On Windows, a directory cannot be removed while it is the working
directory of the process (thanks to Johannes Sixt on the Git list
for this info [1]).

This commit eliminates the 'cd' into the tmp directory that caused
the error.

[1]: http://article.gmane.org/gmane.comp.version-control.git/193086Signed-off-by: NTim Henigan <tim.henigan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There were 3 instances of a 'while read; do' that used identical logic
to populate '/tmp/right_dir'. This commit groups them into a single loop.
Signed-off-by: NTim Henigan <tim.henigan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The 'tar' utility is not available on all platforms (some only support
'gnutar').  An earlier commit created a work-around for this problem,
but a better solution is to eliminate the use of 'tar' completely.
Signed-off-by: NTim Henigan <tim.henigan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

mktemp is not available on all platforms.  Instead of littering the code
with a work-around, this commit replaces mktemp with a one-line Perl
script.
Signed-off-by: NTim Henigan <tim.henigan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The comment from an earlier commit did not reflect the actual reason this
operation is needed.
Signed-off-by: NTim Henigan <tim.henigan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The previous description was confusing.  This rewrite makes it easier
to understand.
Signed-off-by: NTim Henigan <tim.henigan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The auto detection was testing if a fixed string that is known to be
non-empty is empty by mistake.

* jc/i18n-shell-script-gettext:
  i18n: fix auto detection of gettext scheme for shell scripts

It was unclear what a test in t0204 wanted to check; it turns out
that it was only to observe an undefined behaviour of the system,
and did not anticipate one kind of reasonable error behaviour.

* jc/maint-undefined-i18n-observation-test:
  t0204: clarify the "observe undefined behaviour" test

When "git config" diagnoses an error in a configuration file and
shows the line number for the offending line, it miscounted if the
error was at the end of line.

By Martin Stenberg
* ms/maint-config-error-at-eol-linecount:
  config: report errors at the EOL with correct line number

Conflicts:
	t/t1300-repo-config.sh

By Phil Hord
* ph/rerere-doc:
  rerere: Document 'rerere remaining'

We have had these options as harmless no-op for more than 3 years without
officially deprecating them.  Let's announce the deprecation and start
warning against their use, but without failing the command just not yet,
so that we can later repurpose the option if we want to in the future.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

"git tag -s" honored "gpg.program" configuration variable since
1.7.9, but "git tag -v" and "git verify-tag" didn't.

By Alex Zepeda
* az/verify-tag-use-gpg-config:
  verify-tag: Parse GPG configuration options.

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

"git bundle" did not record boundary commits correctly when there
are many of them.

By Thomas Rast
* tr/maint-bundle-boundary:
  bundle: keep around names passed to add_pending_object()
  t5510: ensure we stay in the toplevel test dir
  t5510: refactor bundle->pack conversion

"git diff-index" and its friends at the plumbing level showed the
"diff --git" header and nothing else for a path whose cached stat
info is dirty without actual difference when asked to produce a
patch. This was a longstanding bug that we could have fixed long
time ago.

By Junio C Hamano
* jc/maint-diff-patch-header:
  diff -p: squelch "diff --git" header for stat-dirty paths
  t4011: illustrate "diff-index -p" on stat-dirty paths
  t4011: modernise style

"gitweb" did use quotemeta() to prepare search string when asked to
do a fixed-string project search, but did not use it by mistake and
used the user-supplied string instead.

By Jakub Narebski
* jn/maint-do-not-match-with-unsanitized-searchtext:
  gitweb: Fix fixed string (non-regexp) project search

The code to synthesize the fake ancestor tree used by 3-way merge
fallback in "git am" was not prepared to read a patch created with
a non-standard -p<num> value.

* jc/am-3-nonstandard-popt:
  test: "am -3" can accept non-standard -p<num>
  am -3: allow nonstandard -p<num> option

The --binary option to git-apply has been a no-op since 2b6eef94 (Make
apply --binary a no-op., 2006-09-06) and was deprecated in cb3a160d
(git-am: ignore --binary option, 2008-08-09).

We could remove it outright, but let's be nice to people who still
have scripts saying 'git am -b' (if they exist) and tell them the
reason for the sudden failure.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>