This function is a single-liner and is only called from one
place. Just inline it, which makes the code more obvious.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we encounter an unknown http error (e.g., a 403), we
hand the error code to http_error, which then prints it with
error(). After that we die with the redundant message "HTTP
request failed".

Instead, let's just drop http_error entirely, which does
nothing but pass arguments to error(), and instead die
directly with a useful message.

So before:

  $ git clone https://example.com/repo.git
  Cloning into 'repo'...
  error: unable to access 'https://example.com/repo.git': The requested URL returned error: 403 Forbidden
  fatal: HTTP request failed

and after:

  $ git clone https://example.com/repo.git
  Cloning into 'repo'...
  fatal: unable to access 'https://example.com/repo.git': The requested URL returned error: 403 Forbidden
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we report an http error code, we say something like:

  error: The requested URL reported failure: 403 Forbidden while accessing http://example.com/repo.git

Everything between "error:" and "while" is written by curl,
and the resulting sentence is hard to read (especially
because there is no punctuation between curl's sentence and
the remainder of ours). Instead, let's re-order this to give
better flow:

  error: unable to access 'http://example.com/repo.git: The requested URL reported failure: 403 Forbidden

This is still annoyingly long, but at least reads more
clearly left to right.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This helper function should really be a one-liner that
prints an error message, but it has ended up unnecessarily
complicated:

  1. We call error() directly when we fail to start the curl
     request, so we must later avoid printing a duplicate
     error in http_error().

     It would be much simpler in this case to just stuff the
     error message into our usual curl_errorstr buffer
     rather than printing it ourselves. This means that
     http_error does not even have to care about curl's exit
     value (the interesting part is in the errorstr buffer
     already).

  2. We return the "ret" value passed in to us, but none of
     the callers actually cares about our return value. We
     can just drop this entirely.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we report http errors in fetching the initial ref
advertisement, we show the full URL we attempted to use,
including "info/refs?service=git-upload-pack". While this
may be useful for debugging a broken server, it is
unnecessarily verbose and confusing for most cases, in which
the client user is not even the same person as the owner of
the repository.

Let's just show the repository URL; debugging can happen
with GIT_CURL_VERBOSE, which shows way more useful
information, anyway.

At the same time, let's also make sure to mention the
repository URL when we report failed authentication
(previously we said only "Authentication failed"). Knowing
the URL can help the user realize why authentication failed
(e.g., they meant to push to remote A, not remote B).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we get an http 404 trying to get the initial list of
refs from the server, we try to be helpful and remind the
user that update-server-info may need to be run. This looks
like:

  $ git clone https://github.com/non/existent
  Cloning into 'existent'...
  fatal: https://github.com/non/existent/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?

Suggesting update-server-info may be a good suggestion for
users who are in control of the server repo and who are
planning to set up dumb http. But for users of smart http,
and especially users who are not in control of the server
repo, the advice is useless and confusing.

Since most people are expected to use smart http these days,
it does not make sense to keep the update-server-info hint.

We not only drop the mention of update-server-info, but also
show only the main repo URL, not the full "info/refs" and
service parameter. These elements may be useful for
debugging a broken server configuration, but in the majority
of cases, users are not fetching from their own
repositories, but rather from other people's repositories;
they have neither the power nor interest to fix a broken
configuration, and the extra components just make the
message more confusing. Users who do want to debug can and
should use GIT_CURL_VERBOSE to get more complete information
on the actual URLs visited.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When we get an http 404 trying to get the initial list of
refs from the server, we try to be helpful and remind the
user that update-server-info may need to be run. This looks
like:

  $ git clone https://github.com/non/existent
  Cloning into 'existent'...
  fatal: https://github.com/non/existent/info/refs?service=git-upload-pack not found: did you run git update-server-info on the server?

Suggesting update-server-info may be a good suggestion for
users who are in control of the server repo and who are
planning to set up dumb http. But for users of smart http,
and especially users who are not in control of the server
repo, the advice is useless and confusing.

The previous patch taught remote-curl to show custom advice
from the server when it is available. When we have shown
messages from the server, we can also drop our custom
advice; what the server has to say is likely to be more
accurate and helpful.

We not only drop the mention of update-server-info, but also
show only the main repo URL, not the full "info/refs" and
service parameter. These elements may be useful for
debugging a broken server configuration, but again, anything
the server has provided is likely to be more useful (and one
can still use GIT_CURL_VERBOSE to get much more complete
debugging information).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If an http request to a remote git server fails, we show
only the http response code, or sometimes a custom message
for particular codes. This gives the server no opportunity
to offer a more detailed explanation of the reason for the
failure, or to give extra advice.

This patch teaches remote-curl to record and display the
body content of a failed http response. We only display such
responses when the content-type is advertised as text/plain,
as it is the most likely to look presentable on the user's
terminal (and it is hoped to be a good indication that the
message is intended for git clients, and not for a web
browser).

Each line of the new output is prepended with "remote:".
Example output may look like this (assuming the server is
configured to display such a helpful message):

  $ GIT_SMART_HTTP=0 git clone https://example.com/some/repo.git
  Cloning into 'repo'...
  remote: Sorry, fetching via dumb http is forbidden.
  remote: Please upgrade your git client to v1.6.6 or greater
  remote: and make sure that smart-http is enabled.
  error: The requested URL returned error: 403 while accessing http://localhost:5001/some/repo.git/info/refs
  fatal: HTTP request failed

For the sake of simplicity, we only record and display these
errors during the initial fetch of the ref list, as that is
the initial contact with the server and where the most
common, interesting errors happen (and there is already
precedent, as that is the only place we currently massage
http error codes into more helpful messages).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We currently set curl's FAILONERROR option, which means that
any http failures are reported as curl errors, and the
http body content from the server is thrown away.

This patch introduces a new option to http_get_strbuf which
specifies that the body content from a failed http response
should be placed in the destination strbuf, where it can be
accessed by the caller.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

"rev-parse --verify" was documented in a misleading way.

* mh/rev-parse-verify-doc:
  rev-parse: clarify documentation for the --verify option

Teach "merge/pull" to optionally verify and reject commits that are
not signed properly.

* sg/gpg-sig:
  pretty printing: extend %G? to include 'N' and 'U'
  merge/pull Check for untrusted good GPG signatures
  merge/pull: verify GPG signatures of commits being merged
  commit.c/GPG signature verification: Also look at the first GPG status line
  Move commit GPG signature verification to commit.c

A finishing touch to the new topic in 1.8.3.

* jl/submodule-deinit:
  submodule deinit: clarify work tree removal message

Update "git send-email" for issues noticed by PerlCritic.

* rr/send-email-perl-critique:
  send-email: use the three-arg form of open in recipients_cmd
  send-email: drop misleading function prototype
  send-email: use "return;" not "return undef;" on error codepaths

"git merge $(git rev-parse v1.8.2)" behaved quite differently from
"git merge v1.8.2" as if v1.8.2 were written as v1.8.2^0 and did
not pay much attention to the annotated tag payload.

This makes the code notice the type of the tag object, in addition
to the dwim_ref() based classification the current code uses
(i.e. the name appears in refs/tags/) to decide when to special
case merging of tags.

* jc/merge-tag-object:
  t6200: test message for merging of an annotated tag
  t6200: use test_config/test_unconfig
  merge: a random object may not necssarily be a commit

* maint:
  mailmap: update Pasky's address
  git-remote-mediawiki: new wiki URL in documentation

Eric Wong noticed that the address at suse.cz no longer works.
We may want to update in-code addresses as well, but let's do
this first in 'maint'.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* nd/index-pack-threaded-fixes:
  index-pack: guard nr_resolved_deltas reads by lock
  index-pack: protect deepest_delta in multithread code

* jk/index-pack-correct-depth-fix:
  index-pack: always zero-initialize object_entry list

"submodule summary --summary-limit" option did not support
"--option=value" form.

* rs/submodule-summary-limit:
  submodule summary: support --summary-limit=<n>

* jk/peel-ref:
  upload-pack: load non-tip "want" objects from disk
  upload-pack: make sure "want" objects are parsed
  upload-pack: drop lookup-before-parse optimization

The Bibzball wiki is not maintained anymore.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

There was no good way to ask "I have a random string that came from
outside world. I want to turn it into a 40-hex object name while
making sure such an object exists".  A new peeling suffix ^{object}
can be used for that purpose, together with "rev-parse --verify".

* jc/sha1-name-object-peeler:
  peel_onion(): teach $foo^{object} peeler
  peel_onion: disambiguate to favor tree-ish when we know we want a tree-ish

Update a test to match the documented interaction between pushURL
and pushInsteadOf.

* jc/t5516-pushInsteadOf-vs-pushURL:
  t5516: test interaction between pushURL and pushInsteadOf correctly

"submodule summary --summary-limit" option did not support
"--option=value" form.

* rs/submodule-summary-limit:
  submodule summary: support --summary-limit=<n>

Let us use not just memgrind but other *grind debuggers.

* tr/valgrind:
  tests: notice valgrind error in test_must_fail
  tests --valgrind: provide a mode without --track-origins
  tests: parameterize --valgrind option
  t/README: --valgrind already implies -v

The prompt string generator did not notice when we are in a middle
of a "git revert" session.

* rr/prompt-revert-head:
  bash: teach __git_ps1 about REVERT_HEAD

"git branch -m" without any argument noticed an error, but with an
incorrect error message.

* jm/branch-rename-nothing-error:
  branch: give better message when no names specified for rename

Add more logic to detect graphic environment of OS X by simply
checking TERM_PROGRAM has some value, not Apple_Terminal, to detect
iTerm.app and any other.

* js/iterm-is-on-osx:
  git-web--browse: recognize any TERM_PROGRAM as a GUI terminal on OS X

Have the streaming interface and other codepaths more carefully
examine for corrupt objects.

* jk/check-corrupt-objects-carefully:
  clone: leave repo in place after checkout errors
  clone: run check_everything_connected
  clone: die on errors from unpack_trees
  add tests for cloning corrupted repositories
  streaming_write_entry: propagate streaming errors
  add test for streaming corrupt blobs
  avoid infinite loop in read_istream_loose
  read_istream_filtered: propagate read error from upstream
  check_sha1_signature: check return value from read_istream
  stream_blob_to_fd: detect errors reading from stream

"git apply --whitespace=fix" was not prepared to see a line getting
longer after fixing whitespaces (e.g. tab-in-indent aka Python).

* jc/apply-ws-fix-tab-in-indent:
  test: resurrect q_to_tab
  apply --whitespace=fix: avoid running over the postimage buffer

Try to be careful when difftool backend allows the user to write
into the temporary files being shown *and* the user makes changes
to the working tree at the same time. One of the changes has to be
lost in such a case, but at least tell the user what he did.

* jk/difftool-no-overwrite-on-copyback:
  t7800: run --dir-diff tests with and without symlinks
  t7800: fix tests when difftool uses --no-symlinks
  t7800: don't hide grep output
  difftool: don't overwrite modified files
  t7800: move '--symlinks' specific test to the end

Fix 1.8.1.x regression that stopped matching "dir" (without
trailing slash) to a directory "dir".

* jc/directory-attrs-regression-fix:
  t: check that a pattern without trailing slash matches a directory
  dir.c::match_pathname(): pay attention to the length of string parameters
  dir.c::match_pathname(): adjust patternlen when shifting pattern
  dir.c::match_basename(): pay attention to the length of string parameters
  attr.c::path_matches(): special case paths that end with a slash
  attr.c::path_matches(): the basename is part of the pathname

Consolidate repeated pathspec matches on the same paths, while
fixing a bug in "git checkout dir/" code started from an unmerged
index.

* nd/checkout-paths-reduce-match-pathspec-calls:
  checkout: avoid unnecessary match_pathspec calls

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

Verification of signed tags were not done correctly when not in C
or en/US locale.

* mg/gpg-interface-using-status:
  pretty: make %GK output the signing key for signed commits
  pretty: parse the gpg status lines rather than the output
  gpg_interface: allow to request status return
  log-tree: rely upon the check in the gpg_interface
  gpg-interface: check good signature in a reliable way

'git commit -m "$msg"' used to add an extra newline even when
$msg already ended with one.

* bc/commit-complete-lines-given-via-m-option:
  Documentation/git-commit.txt: rework the --cleanup section
  git-commit: only append a newline to -m mesg if necessary
  t7502: demonstrate breakage with a commit message with trailing newlines
  t/t7502: compare entire commit message with what was expected

The "--match=<pattern>" option of "git describe", when used with
"--all" to allow refs that are not annotated tags to be used as a
base of description, did not restrict the output from the command to
those that match the given pattern.

* jc/describe:
  describe: --match=<pattern> must limit the refs even when used with --all