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>
l10n: Update git.pot (5 new, 3 removed messages)

Generate po/git.pot from v1.7.11-rc0-100-g5498c:

 * 5 new l10n messages at lines:
   635, 639, 1203, 1208, 3946

 * 3 removed l10n messages at lines:
   1194, 3158, 3936

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
l10n: zh_CN.po: translate 2 new, 3 fuzzy messages

Translate 2 new and 3 fuzzy messages came from git.pot update
in 75f7b4b (l10n: Update git.pot (5 new, 3 removed messages)).

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
l10n: de.po: translate 265 new messages

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
l10n: de.po: translate 41 new messages

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
l10n: de.po: translate 2 new, 3 fuzzy messages

Translate 2 new and 3 fuzzy messages came from git.pot update
in 75f7b4b (l10n: Update git.pot (5 new, 3 removed messages)).

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
l10n: de.po: add additional newline

The translation of "builtin/gc.c:224" was missing of
a newline which made the second part of the message
quite long. We simply add a newline.

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.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>
Merge branch 'ef/maint-rebase-error-message' into maint

When "git rebase" was given a bad commit to replay the history on,
its error message did not correctly give the command line argument
it had trouble parsing.

By Erik Faye-Lund
* ef/maint-rebase-error-message:
  rebase: report invalid commit correctly
Git 1.7.10.4

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with 1.7.10.4

* maint:
  Git 1.7.10.4
Git 1.7.11-rc1

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with 1.7.11-rc1

* master:
  Git 1.7.11-rc1
  Git 1.7.10.4
ls-files -i: pay attention to exclusion of leading paths

"git ls-files --exclude=t/ -i" does not show paths in directory t/
that have been added to the index, but it should.

The excluded() API was designed for callers who walk the tree from
the top, checking each level of the directory hierarchy as it
descends if it is excluded, and not even bothering to recurse into
an excluded directory.  This would allow us optimize for a common
case by not having to check if the exclude pattern "foo/" matches
when looking at "foo/bar", because the caller should have noticed
that "foo" is excluded and did not even bother to read "foo/bar"
out of opendir()/readdir() to call it.

The code for "ls-files -i" however walks the index linearly, feeding
paths without checking if the leading directory is already excluded.

Introduce a helper function path_excluded() to let this caller
properly call excluded() check for higher hierarchies as necessary.

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