Merge branch 'jk/bisect-prn-unsigned'

* jk/bisect-prn-unsigned:
  bisect: avoid signed integer overflow

Merge branch 'rr/triangle'

Support "pull from one place, push to another place" workflow
better by introducing remote.pushdefault (overrides the "origin"
thing) and branch.*.pushremote (overrides the branch.*.remote).

* rr/triangle:
  remote.c: introduce branch.<name>.pushremote
  remote.c: introduce remote.pushdefault
  remote.c: introduce a way to have different remotes for fetch/push
  t5516 (fetch-push): drop implicit arguments from helper functions
  t5516 (fetch-push): update test description
  remote.c: simplify a bit of code using git_config_string()

Merge branch 'mm/status-during-revert'

"git status" learned to report that you are in the middle of a
revert session, just like it does for a cherry-pick and a bisect
session.

* mm/status-during-revert:
  status: show commit sha1 in "You are currently reverting" message
  status: show 'revert' state and status hint

Merge branch 'jk/set-upstream-error-cases'

The handing by "git branch --set-upstream-to" against various forms
of errorneous inputs were suboptimal.

* jk/set-upstream-error-cases:
  branch: give advice when tracking start-point is missing
  branch: mention start_name in set-upstream error messages
  branch: improve error message for missing --set-upstream-to ref
  branch: factor out "upstream is not a branch" error messages
  t3200: test --set-upstream-to with bogus refs

Merge branch 'jk/filter-branch-come-back-to-original'

When used with "-d temporary-directory" option, "git filter-branch"
failed to come back to the original working tree to perform the
final clean-up procedure.

* jk/filter-branch-come-back-to-original:
  filter-branch: return to original dir after filtering

format-patch: trivial cleanups

Now that the cover-letter code has been shuffled, we can do some
cleanups.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

format-patch: add format.coverLetter configuration variable

Also, add a new option: 'auto', so if there's more than one patch, the
cover letter is generated, otherwise it's not.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

log: update to OPT_BOOL

OPT_BOOLEAN is deprecated, and this is what we want.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

format-patch: refactor branch name calculation

By moving the part that relies on rev->pending earlier, where we are
already checking the special case where there's only one ref.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

format-patch: improve head calculation for cover-letter

If we do it after the revision traversal we can be sure that this is
indeed a commit that will be processed (i.e. not a merge) and it's the
top most one (thus removing the NEEDSWORK comment, at least we show the
same as 'git diff --stat' output that appears in the cover-letter).

While we are at it, since we know there's nothing to generate, exit
sooner in all cases, like --cover-letter currently does.

Also, if there's nothing to generate and cover-letter is specified, a
different code-path might be triggered that is not currently covered in
the test-case, so add a test for it.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

Sync with 1.8.1.6

fmt-merge-msg: use core.commentchar in tag signatures completely

Commit eff80a9 (Allow custom "comment char") introduced a custom
comment character for commit messages but didn't use it completely
in the tag signature part.

This commit fixes that.

Signed-off-by: Ralf Thielow <redacted>
Signed-off-by: Junio C Hamano <redacted>

fmt-merge-msg: respect core.commentchar in people credits

Commit eff80a9 (Allow custom "comment char") introduced a custom
comment character for commit messages but forgot to use it in
people credits which can be a part of a commit message.

With this commit, the custom comment character is also used
in people credits.

Signed-off-by: Ralf Thielow <redacted>
Signed-off-by: Junio C Hamano <redacted>

Git 1.8.1.6

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'jc/directory-attrs-regression-fix' into maint-1.8.1

A pattern "dir" (without trailing slash) in the attributes file
stopped matching a directory "dir" by mistake with an earlier change
that wanted to allow pattern "dir/" to also match.

* 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

remote-helpers/test-bzr.sh: do not use "grep '\s'"

Using grep "devel\s\+3:" to find at least one whitspace is not
portable on all grep versions; not all grep versions understand "\s"
as a "whitespace".

Use a literal TAB followed by SPACE.

The + as a qualifier for "one or more" is not a basic regular
expression; use egrep instead of grep.

Signed-off-by: Torsten Bögershausen <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: make annotate configurable

Some people always do --annotate, lets not force them to always type
that.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

gitremote-helpers(1): clarify refspec behaviour

The documentation says that "If no 'refspec' capability is advertised,
there is an implied `refspec *:*`" but this is only the case for the
"import" command.

Since there is a comment in transport-helper.c indicating that this
default is for historical reasons, change the documentation to clarify
that a refspec should always be specified.

Signed-off-by: John Keeping <redacted>
Acked-by: Sverre Rabbelier <redacted>
Signed-off-by: Junio C Hamano <redacted>

fast-export: Allow pruned-references in mark file

fast-export can fail because of some pruned-reference when importing a
mark file.

The problem happens in the following scenario:

    $ git fast-export --export-marks=MARKS master
    (rewrite master)
    $ git prune
    $ git fast-export --import-marks=MARKS master

This might fail if some references have been removed by prune
because some marks will refer to no longer existing commits.
git-fast-export will not need these objects anyway as they were no
longer reachable.

We still need to update last_numid so we don't change the mapping
between marks and objects for remote-helpers.
Unfortunately, the mark file should not be rewritten without lost marks
if no new objects has been exported, as we could lose track of the last
last_numid.

Signed-off-by: Antoine Pelisse <redacted>
Reviewed-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: add utf-8 support for pushing

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: add utf-8 support for fetching

[fc: added tests]

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: avoid unreferred tags

They have no content, there's nothing we can do with them.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: only update workingtree on local repos

Apparently, that's the only way it's possible.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: set author if available

[fc: added tests]

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: remove files before modifications

Allow re-add of a deleted file in the same commit.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: fix directory renaming

Git does not handle directories, renaming a directory is renaming every
files in this directory.

[fc: added tests]

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

show-branch: use strbuf instead of static buffer

When we generate relative names (e.g., "master~20^2"), we
format the name into a static buffer, then xstrdup the
result to attach it to the commit. Since the first thing we
add into the static buffer is the already-computed name of
the child commit, the names may get longer and longer as
the traversal gets deeper, and we may eventually overflow
the fixed-size buffer.

Fix this by converting the fixed-size buffer into a dynamic
strbuf.  The performance implications should be minimal, as
we end up allocating a heap copy of the name anyway (and now
we can just detach the heap copy from the strbuf).

Reported-by: Eric Roman <redacted>
Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

http: drop http_error function

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: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-curl: die directly with http error messages

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: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

http: re-word http error message

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: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

http: simplify http_error helper function

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: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-curl: consistently report repo url for http errors

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: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-curl: always show friendlier 404 message

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: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-curl: let servers override http 404 advice

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: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-curl: show server content on http errors

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: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

http: add HTTP_KEEP_ERROR option

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: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Update draft release notes to 1.8.3

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'mh/rev-parse-verify-doc'

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

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

Merge branch 'sg/gpg-sig'

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

Merge branch 'jl/submodule-deinit'

A finishing touch to the new topic in 1.8.3.

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

Merge branch 'rr/send-email-perl-critique'

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

Merge branch 'jc/merge-tag-object'

"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

path.c: optimize adjust_shared_perm()

Sometimes the chown() function is called even when not needed (This
can be provoked by running t1301, and adding some debug code).

Save a chmod from 400 to 400, or from 600 to 600 on these files:

 .git/info/refs+
 .git/objects/info/packs+

Save chmod on directories from 2770 to 2770:

 .git/refs
 .git/refs/heads
 .git/refs/tags

Signed-off-by: Torsten Bögershausen <redacted>
Signed-off-by: Junio C Hamano <redacted>

path.c: simplify adjust_shared_perm()

All calls to set_shared_perm() use mode == 0, so simplify the
function.

Because all callers use the macro adjust_shared_perm(path) from
cache.h to call this function, convert it to a proper function,
losing set_shared_perm().

Since path.c has much more functions than just mkpath() these days,
drop the stale comment about it.

Signed-off-by: Torsten Bögershausen <redacted>
Signed-off-by: Junio C Hamano <redacted>

submodule: print graph output next to submodule log

When running "git log -p --submodule=log", the submodule log is not
indented by the graph output, although all other lines are.  Fix this by
prepending the current line prefix to each line of the submodule log.

Signed-off-by: John Keeping <redacted>
Signed-off-by: Junio C Hamano <redacted>

diff: allow unstuck arguments with --diff-algorithm

The argument to --diff-algorithm is mandatory, so there is no reason to
require the argument to be stuck to the option with '='.  Change this
for consistency with other Git commands.

Note that this does not change the handling of diff-algorithm in
merge-recursive.c since the primary interface to that is via the -X
option to 'git merge' where the unstuck form does not make sense.

Signed-off-by: John Keeping <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-merge(1): document diff-algorithm option to merge-recursive

Commit 07924d4 (diff: Introduce --diff-algorithm command line option
2013-01-16) added diff-algorithm as a parameter to the recursive merge
strategy but did not document it.  Do so.

Signed-off-by: John Keeping <redacted>
Signed-off-by: Junio C Hamano <redacted>

glossary: extend "detached HEAD" description

When we introduced the concept of "detached HEAD", we made sure that
commands that operate on the history of the current branch "just
work" in that state.  They update the HEAD to point at the new
history without affecting any branch when the HEAD is detached, just
like they update the tip of the "current branch" to point at the new
history when HEAD points at a specific branch.

As this is done as the natural extension for these commands, we did
not, we still do not, and we do not want to repeat "A detached HEAD
is updated without affecting any branch" when describing what each
and every one of these commands that operates "on the current branch"
does.

Add a blanket description to the glossary to cover them instead.
The general principle is that operations to update the branch work
on and affect the HEAD, while operations to update the information
about a branch do not.

Signed-off-by: Junio C Hamano <redacted>

log -L: fix overlapping input ranges

The existing code was too defensive, and would trigger the assert in
range_set_append() if the user gave overlapping ranges.

The intent was always to define overlapping ranges as just the union
of all of them, as evidenced by the call to sort_and_merge_range_set().
(Which was already used, unlike what the comment said.)

Fix by splitting out the meat of range_set_append() to a new _unsafe()
function that lacks the paranoia.  sort_and_merge_range_set will fix
up the ranges, so we don't need the checks there.

Signed-off-by: Thomas Rast <redacted>
Signed-off-by: Junio C Hamano <redacted>

log -L: check range set invariants when we look it up

lookup_line_range() is a good place to check that the range sets
satisfy the invariants: they have been computed and set in earlier
iterations, and we now start working with them.

Signed-off-by: Thomas Rast <redacted>
Signed-off-by: Junio C Hamano <redacted>

diffcore-pickaxe: unify code for log -S/-G

The logic flow of has_changes() used for "log -S" and diff_grep()
used for "log -G" are essentially the same.  See if we have both
sides that could be different in any interesting way, slurp the
contents in core, possibly after applying textconv, inspect the
contents, clean-up and report the result.  The only difference
between the two is how "inspect" step works.

Unify this codeflow in a helper, pickaxe_match(), which takes a
callback function that implements the specific "inspect" step.

After removing the common scaffolding code from the existing
has_changes() and diff_grep(), they each becomes such a callback
function suitable for passing to pickaxe_match().

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

diffcore-pickaxe: fix leaks in "log -S<block>" and "log -G<pattern>"

The diff_grep() and has_changes() functions had early return
codepaths for unmerged filepairs, which simply returned 0.  When we
taught textconv filter to them, one was ignored and continued to
return early without freeing the result filtered by textconv, and
the other had a failed attempt to fix, which allowed the planned
return value 0 to be overwritten by a bogus call to contains().

Signed-off-by: Junio C Hamano <redacted>

diffcore-pickaxe: port optimization from has_changes() to diff_grep()

These two functions are called in the same codeflow to implement
"log -S<block>" and "log -G<pattern>", respectively, but the latter
lacked two obvious optimizations the former implemented, namely:

 - When a pickaxe limit is not given at all, they should return
   without wasting any cycle;

 - When both sides of the filepair are the same, and the same
   textconv conversion apply to them, return early, as there will be
   no interesting differences between the two anyway.

Also release the filespec data once the processing is done (this is
not about leaking memory--it is about releasing data we finished
looking at as early as possible).

Signed-off-by: Junio C Hamano <redacted>

diffcore-pickaxe: respect --no-textconv

git log -S doesn't respect --no-textconv:

    $ echo '*.txt diff=wrong' > .gitattributes
    $ git -c diff.wrong.textconv='xxx' log --no-textconv -Sfoo
    error: cannot run xxx: No such file or directory
    fatal: unable to read files to diff

Reported-by: Matthieu Moy <redacted>
Signed-off-by: Simon Ruderich <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation/git-commit: reword the --amend explanation

The explanation for 'git commit --amend' talks about preparing a tree
object, which shouldn't be how user-facing documentation talks about
commit.

Reword it to say it works as usual, but replaces the current commit.

Signed-off-by: Carlos Martín Nieto <redacted>
Signed-off-by: Junio C Hamano <redacted>

t3600: document failure of rm across symbolic links

If we have a symlink "d" that points to a directory, we
should not be able to remove "d/f". In the normal case,
where "d/f" does not exist in the index, we already disallow
this, as we only remove things that git knows about in the
index. So for something like:

  ln -s /outside/repo foo
  git add foo
  git rm foo/bar

we will properly produce an error (as there is no index
entry for foo/bar). However, if there is an index entry for
the path (e.g., because the movement is due to working tree
changes that have not yet been reflected in the index), we
will happily delete it, even though the path we delete from the
filesystem is not the same as the path in the index.

This patch documents that failure with a test.

While this is a bug, it should not be possible to cause
serious data loss with it. For any path that does not have
an index entry, we will complain and bail. For a path which
does have an index entry, we will do the usual up-to-date
content check. So even if the deleted path in the filesystem
is not the same as the one we are removing from the index,
we do know that they at least have the same content, and
that the content is included in HEAD.

That means the worst case is not the accidental loss of
content, but rather confusion by the user when a copy of a
file another part of the tree is removed. Which makes this
bug a minor and hard-to-trigger annoyance rather than a
data-loss bug (and hence the fix can be saved for a rainy
day when somebody feels like working on it).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

diffcore-pickaxe: remove fill_one()

fill_one is _almost_ identical to just calling fill_textconv; the
exception is that for the !DIFF_FILE_VALID case, fill_textconv gives us
an empty buffer rather than a NULL one. Since we currently use the NULL
pointer as a signal that the file is not present on one side of the
diff, we must now switch to using DIFF_FILE_VALID to make the same
check.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Simon Ruderich <redacted>
Signed-off-by: Junio C Hamano <redacted>

diffcore-pickaxe: remove unnecessary call to get_textconv()

The fill_one() function is responsible for finding and filling the
textconv filter as necessary, and is called by diff_grep() function
that implements "git log -G<pattern>".

The has_changes() function that implements "git log -S<block>" calls
get_textconv() for two sides being compared, before it checks to see
if it was asked to perform the pickaxe limiting.  Move the code
around to avoid this wastage.

After has_changes() calls get_textconv() to obtain textconv for both
sides, fill_one() is called to use them.

By adding get_textconv() to diff_grep() and relieving fill_one() of
responsibility to find the textconv filter, we can avoid calling
get_textconv() twice in has_changes().

With this change it's also no longer necessary for fill_one() to
modify the textconv argument, therefore pass a pointer instead of a
pointer to a pointer.

Signed-off-by: Simon Ruderich <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9700: do not close STDERR

Much like the previous patch, this triggered an unrelated bug.
Closing STDERR is not worth it anyway, as we risk writing die() and
such to random files that happen to be subsequently opened on FD 2.
Don't do it.

Signed-off-by: Thomas Rast <redacted>
Reviewed-by: Jonathan Nieder <redacted>
Signed-off-by: Junio C Hamano <redacted>

perl: redirect stderr to /dev/null instead of closing

On my system, t9100.1 triggers the following warning:

  ==352== Syscall param write(buf) points to uninitialised byte(s)
  ==352==    at 0x57119C0: __write_nocancel (in /lib64/libc-2.17.so)
  ==352==    by 0x56AC1D2: _IO_file_write@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
  ==352==    by 0x56AC0B1: new_do_write (in /lib64/libc-2.17.so)
  ==352==    by 0x56AD3B4: _IO_do_write@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
  ==352==    by 0x56AD6FE: _IO_file_overflow@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
  ==352==    by 0x56AE3D8: _IO_default_xsputn (in /lib64/libc-2.17.so)
  ==352==    by 0x56ACAA2: _IO_file_xsputn@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
  ==352==    by 0x5682133: buffered_vfprintf (in /lib64/libc-2.17.so)
  ==352==    by 0x567CE9D: vfprintf (in /lib64/libc-2.17.so)
  ==352==    by 0x5687096: fprintf (in /lib64/libc-2.17.so)
  ==352==    by 0x4E7AC5: vreportf (usage.c:15)
  ==352==    by 0x4E7B14: die_builtin (usage.c:38)

The actual complaint appears to be a bug in the underlying
implementation.  What's interesting here is that it is apparently
_triggered_ by closing stderr, which results in (from strace)

  write(2, "fatal: Needed a single revision\n", 32) = -1 EBADF (Bad file descriptor)
  write(2, "\0", 1) = -1 EBADF (Bad file descriptor)

Closing stderr is a bad idea anyway: there is a very real chance that
we print fatal error messages to some other file that just happens to
be opened on the now-free FD 2.  So let's not do that.

As pointed out by Eric Wong (thanks), the initial close needs to go:
die() would again write nowhere if we close STDERR beforehand.

Signed-off-by: Thomas Rast <redacted>
Signed-off-by: Eric Wong <redacted>
Signed-off-by: Junio C Hamano <redacted>

Sync with maint

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

mailmap: update Pasky's address

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: Junio C Hamano <redacted>

Merge branch 'nd/index-pack-threaded-fixes' into maint

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

Merge branch 'jk/index-pack-correct-depth-fix' into maint

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

Merge branch 'rs/submodule-summary-limit' into maint

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

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

Merge branch 'jk/peel-ref' into maint

* 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

t3600: test behavior of reverse-d/f conflict

The previous commit taught "rm" that it is safe to consider
"d/f" removed when "d" has become a non-directory. This
patch adds a test for the opposite: a file "d" that becomes
a directory.

In this case, "git rm" does need to complain, because we
should not be removing arbitrary content under "d". Git
already behaves correctly, but let's make sure that remains
the case by protecting the behavior with a test.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

rm: do not complain about d/f conflicts during deletion

If we used to have an index entry "d/f", but "d" has been
replaced by a non-directory entry, the user may still want
to run "git rm" to delete the stale index entry. They could
use "git rm --cached" to just touch the index, but "git rm"
should also work: we explicitly try to handle the case that
the file has already been removed from the working tree.

However, because unlinking "d/f" in this case will not yield
ENOENT, but rather ENOTDIR, we do not notice that the file
is already gone. Instead, we report it as an error.

The simple solution is to treat ENOTDIR in this case exactly
like ENOENT; all we want to know is whether the file is
already gone, and if a leading path is no longer a
directory, then by definition the sub-path is gone.

Reported-by: jpinheiro <redacted>
Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

rerere forget: do not segfault if not all stages are present

The loop that fills in the buffers that are later passed to the merge
driver exits early when not all stages of a path are present in the index.
But since the buffer pointers are not initialized in advance, the
subsequent accesses are undefined.

Initialize buffer pointers in advance to avoid undefined behavior later.

That is not sufficient, though, to get correct operation of handle_cache().
The function replays a conflicted merge to extract the part inside the
conflict markers. As written, the loop exits early when a stage is missing.
Consequently, the buffers for later stages that would be present in the
index are not filled in and the merge is replayed with incomplete data.

Fix it by investigating all stages of the given path.

Signed-off-by: Johannes Sixt <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-remote-mediawiki: new wiki URL in documentation

The Bibzball wiki is not maintained anymore.

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-hg: fix hg-git test-case

There was some lingering code that shouldn't have been there in the
first place.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: remove stale check code for tests

The fastimport plugin was only required in the early stage of
development.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-helpers: fix the run of all tests

We don't need to check for duplicate test numbers, we don't have them,
and either way test-lint-duplicates doesn't work in this situation.

Also, while we are on it, enable test-lint-shell-syntax to check for sh
errors.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

remote-bzr: avoid echo -n

It's not portable, as reported by test-lint.

Signed-off-by: Felipe Contreras <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation: Strip texinfo anchors to avoid duplicates

This keeps texinfo 5.x happy. See https://bugs.gentoo.org/464210.

Signed-off-by: Martin von Gagern <redacted>
Signed-off-by: Junio C Hamano <redacted>

bisect: avoid signed integer overflow

Signed-off-by: John Keeping <redacted>
Signed-off-by: Junio C Hamano <redacted>

diffcore-break: don't divide by zero

When the source file is empty, the calculation of the merge score
results in a division by zero.  In the situation:

     == preimage ==             == postimage ==

     F (empty file)             F (a large file)
                                E (a new empty file)

it does not make sense to consider F->E as a rename, so it is better not
to break the pre- and post-image of F.

Bail out early in this case to avoid hitting the divide-by-zero.  This
causes the merge score to be left at zero.

Signed-off-by: John Keeping <redacted>
Signed-off-by: Junio C Hamano <redacted>

add -A: only show pathless 'add -A' warning when changes exist outside cwd

In the spirit of the recent similar change for 'git add -u', avoid
pestering users that restrict their attention to a subdirectory and
will not be affected by the coming change in the behavior of pathless
'git add -A'.

Signed-off-by: Jonathan Nieder <redacted>
Signed-off-by: Junio C Hamano <redacted>

add -u: only show pathless 'add -u' warning when changes exist outside cwd

A common workflow in large projects is to chdir into a subdirectory of
interest and only do work there:

cd src
vi foo.c
make test
git add -u
git commit

The upcoming change to 'git add -u' behavior would not affect such a
workflow: when the only changes present are in the current directory,
'git add -u' will add all changes, and whether that happens via an
implicit "." or implicit ":/" parameter is an unimportant
implementation detail.

The warning about use of 'git add -u' with no pathspec is annoying
because it seemingly serves no purpose in this case.  So suppress the
warning unless there are changes outside the cwd that are not being
added.

A previous version of this patch ran two I/O-intensive diff-files
passes: one to find changes outside the cwd, and another to find
changes to add to the index within the cwd.  This version runs one
full-tree diff and decides for each change whether to add it or warn
and suppress it in update_callback.  As a result, even on very large
repositories "git add -u" will not be significantly slower than the
future default behavior ("git add -u :/"), and the slowdown relative
to "git add -u ." should be a useful clue to users of such
repositories to get into the habit of explicitly passing '.'.

Signed-off-by: Jonathan Nieder <redacted>
Acked-by: Jeff King <redacted>
Improved-by: Junio C Hamano <redacted>
Signed-off-by: Junio C Hamano <redacted>

add: make warn_pathless_add() a no-op after first call

Make warn_pathless_add() print its warning the first time it is called
and do nothing if called again.  This will make it easier to show the
warning on the fly when a relevant condition is detected without
risking showing it multiple times when multiple such conditions hold.

Signed-off-by: Jonathan Nieder <redacted>
Signed-off-by: Junio C Hamano <redacted>

add: add a blank line at the end of pathless 'add [-u|-A]' warning

When the commands give an actual output (e.g. when ran with -v), the
output is visually mixed with the warning.

An additional blank line makes the actual output more visible.

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5570: do not assume the "matching" push is the default

Signed-off-by: Brian Gernhardt <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5551: do not assume the "matching" push is the default

Signed-off-by: Brian Gernhardt <redacted>
Signed-off-by: Junio C Hamano <redacted>

t5550: do not assume the "matching" push is the default

Signed-off-by: Brian Gernhardt <redacted>
Signed-off-by: Junio C Hamano <redacted>

Update draft release notes to 1.8.3

Signed-off-by: Junio C Hamano <redacted>

Sync with maint

Merge branch 'jc/sha1-name-object-peeler'

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

Merge branch 'jc/t5516-pushInsteadOf-vs-pushURL'

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

Merge branch 'rs/submodule-summary-limit'

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

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

Merge branch 'tr/valgrind'

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

Merge branch 'rr/prompt-revert-head'

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

Merge branch 'jm/branch-rename-nothing-error'

"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

Merge branch 'js/iterm-is-on-osx'

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

Merge branch 'jk/check-corrupt-objects-carefully'

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

Merge branch 'jc/apply-ws-fix-tab-in-indent'

"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

Merge branch 'jk/difftool-no-overwrite-on-copyback'

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

Merge branch 'jc/directory-attrs-regression-fix'

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

Merge branch 'nd/checkout-paths-reduce-match-pathspec-calls'

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

Update draft release notes to 1.8.2.1

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'mg/gpg-interface-using-status' into maint

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