These slightly improve the reading flow by making it obvious that a list
follows.

Also, make the wording of both headings consistent by changing "contains
%d ref(s)" to "contains this ref"/"contains these %d refs".
Signed-off-by: NLukas Fleischer <git@cryptocrack.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

A more informative message for "complete" bundles was added in commit
8c3710fd (tweak "bundle verify" of a complete history, 2012-06-04).

However, the prerequisites ref list is currently read *after* we
check if it equals zero, which means we never actually use the
number of prerequisite refs to decide when to print the newly
introduced message.  The code incorrectly uses the number of
references recorded in the bundle instead.
Signed-off-by: NLukas Fleischer <git@cryptocrack.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* jk/maint-http-half-auth-push:
  http: fix segfault in handle_curl_result

* rr/git-uri-doc:
  Git url doc: mark ftp/ftps as read-only and deprecate them

* bw/cp-a-is-gnuism:
  tests: "cp -a" is a GNUism

* nd/doc-ignore:
  gitignore.txt: suggestions how to get literal # or ! at the beginning

* jc/doc-long-options:
  gitcli: parse-options lets you omit tail of long options

* jc/maint-t1450-fsck-order-fix:
  t1450: the order the objects are checked is undefined

* rr/test-use-shell-path-not-shell:
  test-lib: use $SHELL_PATH, not $SHELL

* rr/test-make-sure-we-have-git:
  t/test-lib: make sure Git has already been built

* po/maint-docs:
  Doc branch: show -vv option and alternative
  Doc clean: add See Also link
  Doc add: link gitignore
  Doc: separate gitignore pattern sources
  Doc: shallow clone deepens _to_ new depth

* jc/ll-merge-binary-ours:
  ll-merge: warn about inability to merge binary files only when we can't
  attr: "binary" attribute should choose built-in "binary" merge driver
  merge: teach -Xours/-Xtheirs to binary ll-merge driver

* db/doc-custom-xmlto:
  Documentation/Makefile: Allow custom XMLTO binary

Signed-off-by: NRichard Fearn <richardfearn@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we create an http active_request_slot, we can set its
"results" pointer back to local storage. The http code will
fill in the details of how the request went, and we can
access those details even after the slot has been cleaned
up.

Commit 88097030 (http: factor out http error code handling)
switched us from accessing our local results struct directly
to accessing it via the "results" pointer of the slot. That
means we're accessing the slot after it has been marked as
finished, defeating the whole purpose of keeping the results
storage separate.

Most of the time this doesn't matter, as finishing the slot
does not actually clean up the pointer. However, when using
curl's multi interface with the dumb-http revision walker,
we might actually start a new request before handing control
back to the original caller. In that case, we may reuse the
slot, zeroing its results pointer, and leading the original
caller to segfault while looking for its results inside the
slot.

Instead, we need to pass a pointer to our local results
storage to the handle_curl_result function, rather than
relying on the pointer in the slot struct. This matches what
the original code did before the refactoring (which did not
use a separate function, and therefore just accessed the
results struct directly).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

gitweb's feeds sometimes contained committer timestamps in the wrong timezone
due to a misspelling.
Signed-off-by: NDylan Simon <dylan@dylex.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is the documentation part of

1a9d7e9b (attr.c: read .gitattributes from index as well. - 2007-08-14)
06f33c17 (Read attributes from the index that is being checked out - 2009-03-13)
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* 'maint' of git://github.com/git-l10n/git-po:
  l10n: de.po: fix a few minor typos

These tests just want a bit-for-bit identical copy; they do not need
even -H (there is no symbolic link involved) nor -p (there is no
funny permission or ownership issues involved).

Just use "cp -R" instead.
Signed-off-by: NBen Walton <bdwalton@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It is not even worth mentioning their removal; just discourage
people from using them.
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

"git status" honored the ignore=dirty settings in .gitmodules but
"git commit" didn't.

* os/commit-submodule-ignore:
  commit: pay attention to submodule.$name.ignore in .gitmodules

"git receive-pack" (the counterpart to "git push") did not give
progress output while processing objects it received to the puser
when run over the smart-http protocol.

* jk/receive-pack-unpack-error-to-pusher:
  receive-pack: drop "n/a" on unpacker errors
  receive-pack: send pack-processing stderr over sideband
  receive-pack: redirect unpack-objects stdout to /dev/null

A repository created with "git clone --single" had its fetch
refspecs set up just like a clone without "--single", leading the
subsequent "git fetch" to slurp all the other branches, defeating
the whole point of specifying "only this branch".

* rt/maint-clone-single:
  clone --single: limit the fetch refspec to fetched branch

It was unclear in the documentation for "git blame" that it is
unnecessary for users to use the "--follow" option.

* jc/blame-follows-renames:
  git blame: document that it always follows origin across whole-file renames

A patch attached as application/octet-stream (e.g. not text/*) were
mishandled, not correctly honoring Content-Transfer-Encoding
(e.g. base64).

* lt/mailinfo-handle-attachment-more-sanely:
  mailinfo: don't require "text" mime type for attachments

We support backslash escape, but we hide the details behind the phrase
"a shell glob suitable for consumption by fnmatch(3)". So it may not
be obvious how one can get literal # or ! at the beginning of pattern.
Add a few lines on how to work around the magic characters.
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Describe the behaviour, but do warn people against taking it too
literally and expect an abbreviation valid today will stay valid
forever.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NSimon Ruderich <simon@ruderich.org>
Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com>

When a tag T points at an object X that is of a type that is
different from what the tag records as, fsck should report it as an
error.

However, depending on the order X and T are checked individually,
the actual error message can be different.  If X is checked first,
fsck remembers X's type and then when it checks T, it notices that T
records X as a wrong type (i.e. the complaint is about a broken tag
T).  If T is checked first, on the other hand, fsck remembers that we
need to verify X is of the type tag records, and when it later
checks X, it notices that X is of a wrong type (i.e. the complaint
is about a broken object X).

The important thing is that fsck notices such an error and diagnoses
the issue on object X, but the test was expecting that we happen to
check objects in the order to make us detect issues with tag T, not
with object X.  Remove this unwarranted assumption.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

"git submodule frotz" was not diagnosed as "frotz" being an unknown
subcommand to "git submodule"; the user instead got a complaint that
"git submodule status" was run with an unknown path "frotz".

* rr/maint-submodule-unknown-cmd:
  submodule: if $command was not matched, don't parse other args

"git fetch" over http advertised that it supports "deflate", which
is much less common, and did not advertise more common "gzip" on its
Accept-Encoding header.

* sp/maint-http-enable-gzip:
  Enable info/refs gzip decompression in HTTP client

"git fetch" over http had an old workaround for an unlikely server
misconfiguration; it turns out that this hurts debuggability of the
configuration in general, and has been reverted.

* sp/maint-http-info-refs-no-retry:
  Revert "retry request without query when info/refs?query fails"

Fix bad translation of "Receiving objects".
Signed-off-by: NPeter Krefting <peter@softwolves.pp.se>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently "git am" does insane things if the mbox it is given contains
attachments with a MIME type that aren't "text/*".

In particular, it will still decode them, and pass them "one line at a
time" to the mail body filter, but because it has determined that they
aren't text (without actually looking at the contents, just at the mime
type) the "line" will be the encoding line (eg 'base64') rather than a
line of *content*.

Which then will cause the text filtering to fail, because we won't
correctly notice when the attachment text switches from the commit message
to the actual patch. Resulting in a patch failure, even if patch may be a
perfectly well-formed attachment, it's just that the message type may be
(for example) "application/octet-stream" instead of "text/plain".

Just remove all the bogus games with the message_type. The only difference
that code creates is how the data is passed to the filter function
(chunked per-pred-code line or per post-decode line), and that difference
is *wrong*, since chunking things per pre-decode line can never be a
sensible operation, and cannot possibly matter for binary data anyway.

This code goes all the way back to March of 2007, in commit 87ab7992
("builtin-mailinfo.c infrastrcture changes"), and apparently Don used to
pass random mbox contents to git. However, the pre-decode vs post-decode
logic really shouldn't matter even for that case, and more importantly, "I
fed git am crap" is not a valid reason to break *real* patch attachments.

If somebody really cares, and determines that some attachment is binary
data (by looking at the data, not the MIME-type), the whole attachment
should be dismissed, rather than fed in random-sized chunks to
"handle_filter()".
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: Don Zickus <dzickus@redhat.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

Update German and Simplified Chinese translations.

* 'maint' of git://github.com/git-l10n/git-po:
  l10n: de.po: correct translation of a 'rebase' message
  l10n: Improve many translation for zh_CN
  l10n: Unify the translation for '(un)expected'

* jc/maint-log-grep-all-match-1:
  grep.c: make two symbols really file-scope static this time
  t7810-grep: test --all-match with multiple --grep and --author options
  t7810-grep: test interaction of multiple --grep and --author options
  t7810-grep: test multiple --author with --all-match
  t7810-grep: test multiple --grep with and without --all-match
  t7810-grep: bring log --grep tests in common form
  grep.c: mark private file-scope symbols as static
  log: document use of multiple commit limiting options
  log --grep/--author: honor --all-match honored for multiple --grep patterns
  grep: show --debug output only once
  grep: teach --debug option to dump the parse tree