Merge branch 'fc/git-complete-helper' into fc/git-prompt-script

By Michael Haggerty (17) and others
via Junio C Hamano (36) and Jeff King (1)
* fc/git-complete-helper: (54 commits)
  completion: add new __git_complete helper
  Update draft release notes to 1.7.11 (11th batch)
  Git 1.7.10.2
  document submdule.$name.update=none option for gitmodules
  The tenth batch of topics
  Update draft release notes to 1.7.10.2
  checkout: do not corrupt HEAD on empty repo
  apply: remove lego in i18n string in gitdiff_verify_name
  dir: convert to strbuf
  status: refactor colopts handling
  status: respect "-b" for porcelain format
  status: fix null termination with "-b"
  status: refactor null_termination option
  commit: refactor option parsing
  Documentation/git-config: describe and clarify "--local <file>" option
  reflog-walk: tell explicit --date=default from not having --date at all
  clone: fix progress-regression
  grep.c: remove redundant line of code
  checkout (detached): truncate list of orphaned commits at the new HEAD
  t2020-checkout-detach: check for the number of orphaned commits
  ...
completion: remove executable mode

No reason to have it executable. Every way this script is intended to be
used includes the 'source' command.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: split __git_ps1 into a separate script

bash-completion 1.90 shipped with support to load completions
dynamically[1], which means the git completion script wouldn't be loaded
until the user types 'git <tab>'--this creates a problem to people using
__git_ps1(); that function won't be available when the shell is first
created.

For now distributions have workarounded this issue by moving the git
completion to the "compatdir"[2]; this of course is not ideal.

The solution, proposed by Kerrick Staley[3], is to split the git script
in two; the part that deals with __git_ps1() in one (i.e.
git-prompt.sh), and everything else in another (i.e.
git-completion.bash).

Another benefit of this is that zsh user that are not interested in the
bash completion can use it for their prompts, which has been tried
before[4].

The only slight issue is that __gitdir() would be duplicated, but this
is probably not a big deal.

So let's go ahead and move __git_ps1() to a new file.

While at this, I took the liberty to reformat the help text in the new
file.

 [1] http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=99c4f7f25f50a7cb2fce86055bddfe389effa559
 [2] http://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/git&id=974380fabb8f9f412990b17063bf578d98c44a82
 [3] http://mid.gmane.org/CANaWP3w9KDu57aHquRRYt8td_haSWTBKs7zUHy-xu0B61gmr9A@mail.gmail.com
 [4] http://mid.gmane.org/1303824288-15591-1-git-send-email-mstormo@gmail.com

Cc: Kerrick Staley <mail@kerrickstaley.com>
Cc: Marius Storm-Olsen <mstormo@gmail.com>
Cc: Ville Skyttä <ville.skytta@iki.fi>
Cc: Dan McGee <dan@archlinux.org>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
index-pack: hash non-delta objects while reading from stream

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
index-pack: use streaming interface on large blobs (most of the time)

unpack_raw_entry() will not allocate and return decompressed blobs if
they are larger than core.bigFileThreshold. sha1_object() may not be
called on those objects because there's no actual content.

sha1_object() is called later on those objects, where we can safely
use get_data_from_pack() to retrieve blob content for checking.
However we always do that when we definitely need the blob
content. And we often don't.

There are two cases when we may need object content. The first case is
when we find an in-repo blob with the same SHA-1. We need to do
collision test, byte-on-byte. If this test is on, the blob must be
loaded on memory (i.e. no streaming). Normally (e.g. in
fetch/pull/clone) this does not happen because git avoid to send
objects that client already has.

The other case is when --strict is specified and the object in
question is not a blob, which can't happen in reality becase we deal
with large _blobs_ here.

Note: --verify (or git-verify-pack) a pack from current repository
will trigger collision test on every object in the pack, which
effectively disables this patch. This could be easily worked around by
setting GIT_DIR to an imaginary place with no packs.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
index-pack: factor out unpack core from get_data_from_pack

This allows caller to consume large inflated object with a fixed
amount of memory.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule: document handling of relative superproject origin URLs

These tests document how submodule sync and init handle various
kinds of relative super project origin URLs.  The submodule URL
path is ../subrepo.

6 cases are documented:
  foo
  foo/bar
  ./foo
  ./foo/bar
  ../foo
  ../foo/bar

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule: fix handling of relative superproject origin URLs

When the origin URL of the superproject is itself relative, an operation
such as git submodule add, init or sync may result in either the
submodule.{name}.url configuration property of the superproject
referring to the incorrect location or remote.origin.url configuration
property of the submodule referring to the incorrect location or both
these conditions. In some cases, git submodule fails to update
the configuration and fails with an error condition.

The issue arises in these cases because the origin URL of
the superproject needs to be prepended with a prefix that navigates
from the submodule to the superproject so that when the submodule
URL is concatenated the resulting URL is relative to the working tree
of the submodule.

This change fixes handling for relative superproject origin URLs
for 6 cases:
  foo
  foo/bar
  ./foo
  ./foo/bar
  ../foo
  ../foo/bar

In each case, the configuration properties in the superproject's
configuration and the submodule's configuration refer to the
correct, relative, location of the submodule's origin repo. In all cases,
the configured paths are relative to the working trees of the
repositories containing the configuration.

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
index-pack: use streaming interface for collision test on large blobs

When putting whole objects in core is unavoidable, try match object
type and size first before actually inflating.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-objects: use streaming interface for reading large loose blobs

git usually streams large blobs directly to packs. But there are cases
where git can create large loose blobs (unpack-objects or hash-object
over pipe). Or they can come from other git implementations.
core.bigfilethreshold can also be lowered down and introduce a new
wave of large loose blobs.

Use streaming interface to read/compress/write these blobs in one
go. Fall back to normal way if somehow streaming interface cannot be
used.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unindent excluded_from_list()

Return early if el->nr == 0. Unindent one more level for FNM_PATHNAME
code block as this block is getting complex and may need more
indentation.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
exclude: do strcmp as much as possible before fnmatch

this also avoids calling fnmatch() if the non-wildcard prefix is
longer than basename

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7403-*.sh: Avoid use of the nonportable '==' operator

Some shells, including dash, do not support using the '==' string
equality operator. This results in the failure of tests 7-12 with
'test' complaining of an "unexpected operator".

In order to suppress the errors, we replace the '==' operator with
'=', which must be supported by any POSIX shell.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
docs: drop asciidoc7compatible flag

When we made the switch to supporting asciidoc 8 in 4c7100a
(Documentation: adjust to AsciiDoc 8, 2007-06-14), we were
able to leave most of the documentation intact by defining
asciidoc7compatible.

Since commit 6cf378f (docs: stop using asciidoc no-inline-literal,
2012-04-26), we don't support versions of asciidoc older
than 8.4.1, which is when inline literals were introduced.
Therefore there is not much point in keeping our
documentation compatible with asciidoc 7.

So we are now free to drop the asciidoc7compatible flag and
update the documentation itself to assume asciidoc8.
Fortunately, doing the latter is very easy; we weren't using
any of the constructs impacted by asciidoc7compatible, so
there are no changes to make.

The reason is somewhat subtle. The asciidoc7compatible
affects only super/sub-scripts ("^" and "~") and index
terms. We don't use the latter at all. Nor we do we use the
former, but we did have to protect them from accidental
expansion in constructs like "rev^1". However, all of our
uses of "~" and "^" are either in code blocks (which are
rendered literally), or inside backticks. Prior to 6cf378f,
backticks were not inline literals, and needed proper
quoting. But post-6cf378f, we don't have to worry whether we
are using the old or new rules, as those characters are not
interpreted at all in either case.

I verified that the result of "make install-html
install-man" is identical before and after this patch on
asciidoc 8.6.7.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
docs: drop antique comment from Makefile

This comment warns about a bug in asciidoc 6, and points to
a patch from 2005. Since we don't even support versions of
asciidoc that old, we can safely get rid of the warning.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
docs/clone: mention that --local may be ignored

The --local flag is not "treat this like a local
repository", but rather "if we are local, turn on
optimizations". Therefore it does nothing in the case of:

  git clone --local file:///path/to/repo

Let's make that more clear in the documentation.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
clone: allow --no-local to turn off local optimizations

This is basically the same as using "file://", but is a
little less subtle for the end user. It also allows relative
paths to be specified.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
improve no-op push output

When a push is a no-op because all refs are up-to-date, we print
"Everything up-to-date". That is reasonable when push.default is
"matching" (or when a wildcard refspec is given), because "Everything"
pretty obviously means "everything you asked git to push".

But when one of the single-ref push.default modes is used, the
"Everything" is slightly misleading; we only tried to push one thing,
and we should not give the user the impression that the remote is
completely in sync with what is in their local repo.

Instead, let's detect the case that we attempted to push a single ref,
and if so, just show the verbose status table (which includes the
up-to-date ref). We don't want to show it if we tried to push many refs,
because it could be quite long (e.g., in the case of "matching").

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jl/submodule-report-new-path-once' into jch

Will merge to master by 1.7.11 final.

By Jens Lehmann
* jl/submodule-report-new-path-once:
  submodules: print "registered for path" message only once
Merge branch 'mm/levenstein-penalize-deletion-less' into jch

Will merge to master by 1.7.11 final.

By Matthieu Moy
* mm/levenstein-penalize-deletion-less:
  Reduce cost of deletion in levenstein distance (4 -> 3)