tests: move code to run tests under bash into a helper library

The following patch will add tests for the bash prompt functions as a
new test script, which also has to be run under bash.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
tests: add tests for the bash prompt functions in the completion script

The tests cover the discovery of the '.git' directory in the
__gitdir() function in different scenarios, and the prompt itself,
i.e. branch name, detached heads, operations (rebase, merge,
cherry-pick, bisect), and status indicators (dirty, stash, untracked
files; but not the upstream status).

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
request-pull: really favor a matching tag

After tagging the tip of "dev" branch with a "for-linus" tag and
pushing both out, running

	$ git request-pull $url $last_release dev

would produce an output asking the 'dev' branch of $url to be
pulled, because that is what the user asked the message to say.

We already detect this situation locally and include the contents of
the tag in the output; if the $url has that tag, favor that tag
(i.e. "for-linus") in the generated message over the branch name the
user gave us (i.e. "dev") from the command line, to make the output
look more consistent.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
move git_version_string into version.c

The global git_version_string currently lives in git.c, but
doesn't have anything to do with the git wrapper. Let's move
it into its own file, where it will be more appropriate to
build more version-related functions.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
version: add git_user_agent function

This is basically a fancy way of saying "git/$GIT_VERSION",
except that it is overridable at build-time and through the
environment. Which means that people who don't want to
advertise their git version (for privacy or security
reasons) can tweak it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
http: get default user-agent from git_user_agent

This means we will respect the GIT_USER_AGENT build-time
configuration and run-time environment variable.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule: additional regression tests for relative URLs

Some additional tests are added to support regression testing of the changes in the
remainder of the series.

We also add a pristine copy of .gitmodules in anticipation of this being
required by later tests.

Signed-off-by: Jon Seymour <jon.seymour@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>