Merge branch 'nd/dwim-wildcards-as-pathspecs' into maint

"git show 'HEAD:Foo[BAR]Baz'" did not interpret the argument as a
rev, i.e. the object named by the the pathname with wildcard
characters in a tree object.

* nd/dwim-wildcards-as-pathspecs:
  get_sha1: don't die() on bogus search strings
  check_filename: tighten dwim-wildcard ambiguity
  checkout: reorder check_filename conditional

Merge branch 'jk/epipe-in-async' into maint

Handling of errors while writing into our internal asynchronous
process has been made more robust, which reduces flakiness in our
tests.

* jk/epipe-in-async:
  t5504: handle expected output from SIGPIPE death
  test_must_fail: report number of unexpected signal
  fetch-pack: ignore SIGPIPE in sideband demuxer
  write_or_die: handle EPIPE in async threads

Merge branch 'ps/config-error' into maint

Many codepaths forget to check return value from git_config_set();
the function is made to die() to make sure we do not proceed when
setting a configuration variable failed.

* ps/config-error:
  config: rename git_config_set_or_die to git_config_set
  config: rename git_config_set to git_config_set_gently
  compat: die when unable to set core.precomposeunicode
  sequencer: die on config error when saving replay opts
  init-db: die on config errors when initializing empty repo
  clone: die on config error in cmd_clone
  remote: die on config error when manipulating remotes
  remote: die on config error when setting/adding branches
  remote: die on config error when setting URL
  submodule--helper: die on config error when cloning module
  submodule: die on config error when linking modules
  branch: die on config error when editing branch description
  branch: die on config error when unsetting upstream
  branch: report errors in tracking branch setup
  config: introduce set_or_die wrappers

Merge branch 'mg/work-tree-tests' into maint

Traditionally, the tests that try commands that work on the
contents in the working tree were named with "worktree" in their
filenames, but with the recent addition of "git worktree"
subcommand, whose tests are also named similarly, it has become
harder to tell them apart.  The traditional tests have been renamed
to use "work-tree" instead in an attempt to differentiate them.

* mg/work-tree-tests:
  tests: rename work-tree tests to *work-tree*

Merge branch 'sp/remote-curl-ssl-strerror' into maint

Help those who debug http(s) part of the system.

* sp/remote-curl-ssl-strerror:
  remote-curl: include curl_errorstr on SSL setup failures

t5504: handle expected output from SIGPIPE death

Commit 8bf4bec (add "ok=sigpipe" to test_must_fail and use
it to fix flaky tests, 2015-11-27) taught t5504 to handle
"git push" racily exiting with SIGPIPE rather than failing.

However, one of the tests checks the output of the command,
as well. In the SIGPIPE case, we will not have produced any
output. If we want the test to be truly non-flaky, we have
to accept either output.

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

test_must_fail: report number of unexpected signal

If a command is marked as test_must_fail but dies with a
signal, we consider that a problem and report the error to
stderr. However, we don't say _which_ signal; knowing that
can make debugging easier. Let's share as much as we know.

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

fetch-pack: ignore SIGPIPE in sideband demuxer

If the other side feeds us a bogus pack, index-pack (or
unpack-objects) may die early, before consuming all of its
input. As a result, the sideband demuxer may get SIGPIPE
(racily, depending on whether our data made it into the pipe
buffer or not). If this happens and we are compiled with
pthread support, it will take down the main thread, too.

This isn't the end of the world, as the main process will
just die() anyway when it sees index-pack failed. But it
does mean we don't get a chance to say "fatal: index-pack
failed" or similar. And it also means that we racily fail
t5504, as we sometimes die() and sometimes are killed by
SIGPIPE.

So let's ignore SIGPIPE while demuxing the sideband. We are
already careful to check the return value of write(), so we
won't waste time writing to a broken pipe. The caller will
notice the error return from the async thread, though in
practice we don't even get that far, as we die() as soon as
we see that index-pack failed.

The non-sideband case is already fine; we let index-pack
read straight from the socket, so there is no SIGPIPE at
all. Technically the non-threaded async case is also OK
without this (the forked async process gets SIGPIPE), but
it's not worth distinguishing from the threaded case here.

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

write_or_die: handle EPIPE in async threads

When write_or_die() sees EPIPE, it treats it specially by
converting it into a SIGPIPE death. We obviously cannot
ignore it, as the write has failed and the caller expects us
to die. But likewise, we cannot just call die(), because
printing any message at all would be a nuisance during
normal operations.

However, this is a problem if write_or_die() is called from
a thread. Our raised signal ends up killing the whole
process, when logically we just need to kill the thread
(after all, if we are ignoring SIGPIPE, there is good reason
to think that the main thread is expecting to handle it).

Inside an async thread, the die() code already does the
right thing, because we use our custom die_async() routine,
which calls pthread_join(). So ideally we would piggy-back
on that, and simply call:

  die_quietly_with_code(141);

or similar. But refactoring the die code to do this is
surprisingly non-trivial. The die_routines themselves handle
both printing and the decision of the exit code. Every one
of them would have to be modified to take new parameters for
the code, and to tell us to be quiet.

Instead, we can just teach write_or_die() to check for the
async case and handle it specially. We do have to build an
interface to abstract the async exit, but it's simple and
self-contained. If we had many call-sites that wanted to do
this die_quietly_with_code(), this approach wouldn't scale
as well, but we don't. This is the only place where do this
weird exit trick.

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

Git 2.7.2

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

Merge branch 'nd/ita-cleanup' into maint

Paths that have been told the index about with "add -N" are not
quite yet in the index, but a few commands behaved as if they
already are in a harmful way.

* nd/ita-cleanup:
  grep: make it clear i-t-a entries are ignored
  add and use a convenience macro ce_intent_to_add()
  blame: remove obsolete comment

Merge branch 'pw/completion-stash' into maint

* pw/completion-stash:
  completion: fix mis-indentation in _git_stash()

Merge branch 'mm/clean-doc-fix' into maint

The documentation for "git clean" has been corrected; it mentioned
that .git/modules/* are removed by giving two "-f", which has never
been the case.

* mm/clean-doc-fix:
  Documentation/git-clean.txt: don't mention deletion of .git/modules/*

Merge branch 'dw/mergetool-vim-window-shuffle' into maint

The vimdiff backend for "git mergetool" has been tweaked to arrange
and number buffers in the order that would match the expectation of
majority of people who read left to right, then top down and assign
buffers 1 2 3 4 "mentally" to local base remote merge windows based
on that order.

* dw/mergetool-vim-window-shuffle:
  mergetool: reorder vim/gvim buffers in three-way diffs

Merge branch 'ah/stripspace-optstring' into maint

* ah/stripspace-optstring:
  stripspace: call U+0020 a "space" instead of a "blank"

completion: fix mis-indentation in _git_stash()

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: rename git_config_set_or_die to git_config_set

Rename git_config_set_or_die functions to git_config_set, leading
to the new default behavior of dying whenever a configuration
error occurs.

By now all callers that shall die on error have been transitioned
to the _or_die variants, thus making this patch a simple rename
of the functions.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: rename git_config_set to git_config_set_gently

The desired default behavior for `git_config_set` is to die
whenever an error occurs. Dying is the default for a lot of
internal functions when failures occur and is in this case the
right thing to do for most callers as otherwise we might run into
inconsistent repositories without noticing.

As some code may rely on the actual return values for
`git_config_set` we still require the ability to invoke these
functions without aborting. Rename the existing `git_config_set`
functions to `git_config_set_gently` to keep them available for
those callers.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

compat: die when unable to set core.precomposeunicode

When calling `git_config_set` to set 'core.precomposeunicode' we
ignore the return value of the function, which may indicate that
we were unable to write the value back to disk. As the function
is only called by init-db we can and should die when an error
occurs.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sequencer: die on config error when saving replay opts

When we start picking a range of revisions we save the replay
options that are required to restore state when interrupting and
later continuing picking the revisions. However, we do not check
the return values of the `git_config_set` functions, which may
lead us to store incomplete information. As this may lead us to
fail when trying to continue the sequence the error can be fatal.

Fix this by dying immediately when we are unable to write back
any replay option.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

init-db: die on config errors when initializing empty repo

When creating an empty repository with `git init-db` we do not
check for error codes returned by `git_config_set` functions.
This may cause the user to end up with an inconsistent repository
without any indication for the user.

Fix this problem by dying early with an error message when we are
unable to write the configuration files to disk.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

clone: die on config error in cmd_clone

The clone command does not check for error codes returned by
`git_config_set` functions. This may cause the user to end up
with an inconsistent repository without any indication with what
went wrong.

Fix this problem by dying with an error message when we are
unable to write the configuration files to disk.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote: die on config error when manipulating remotes

When manipulating remotes we try to set various configuration
values without checking if the values were persisted correctly,
possibly leaving the remote in an inconsistent state.

Fix this issue by dying early and notifying the user about the
error.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote: die on config error when setting/adding branches

When we add or set new branches (e.g. by `git remote add -f` or
`git remote set-branches`) we do not check for error codes when
writing the branches to the configuration file. When persisting
the configuration failed we are left with a remote that has none
or not all of the branches that should have been set without
notifying the user.

Fix this issue by dying early on configuration error.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote: die on config error when setting URL

When invoking `git-remote --set-url` we do not check the return
value when writing the actual new URL to the configuration file,
pretending to the user that the configuration has been set while
it was in fact not persisted.

Fix this problem by dying early when setting the config fails.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule--helper: die on config error when cloning module

When setting the 'core.worktree' option for a newly cloned
submodule we ignore the return value of `git_config_set_in_file`.
As this leaves the submodule in an inconsistent state, we instead
want to inform the user that something has gone wrong by printing
an error and aborting the program.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule: die on config error when linking modules

When trying to connect a submodule with its corresponding
repository in '.git/modules' we try to set the core.worktree
setting in the submodule, which may fail due to an error
encountered in `git_config_set_in_file`.

The function is used in the git-mv command when trying to move a
submodule to another location. We already die when renaming a
file fails but do not pay attention to the case where updating
the connection between submodule and its repository fails. As
this leaves the repository in an inconsistent state, as well,
abort the program by dying early and presenting the failure to
the user.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

branch: die on config error when editing branch description

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

branch: die on config error when unsetting upstream

When we try to unset upstream configurations we do not check
return codes for the `git_config_set` functions. As those may
indicate that we were unable to unset the respective
configuration we may exit successfully without any error message
while in fact the upstream configuration was not unset.

Fix this by dying with an error message when we cannot unset the
configuration.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

branch: report errors in tracking branch setup

When setting up a new tracking branch fails due to issues with
the configuration file we do not report any errors to the user
and pretend setting the tracking branch succeeded.

Setting up the tracking branch is handled by the
`install_branch_config` function. We do not want to simply die
there as the function is not only invoked when explicitly setting
upstream information with `git branch --set-upstream-to=`, but
also by `git push --set-upstream` and `git clone`. While it is
reasonable to die in the explict first case, we would lose
information in the latter two cases, so we only print the error
message but continue the program as usual.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: rename work-tree tests to *work-tree*

"Work tree" or "working tree" is the name of a checked out tree,
"worktree" the name of the command which manages several working trees.
The naming of tests mixes these two, currently:

$ls t/*worktree*
t/t1501-worktree.sh
t/t1509-root-worktree.sh
t/t2025-worktree-add.sh
t/t2026-worktree-prune.sh
t/t2027-worktree-list.sh
t/t2104-update-index-skip-worktree.sh
t/t3320-notes-merge-worktrees.sh
t/t7011-skip-worktree-reading.sh
t/t7012-skip-worktree-writing.sh
t/t7409-submodule-detached-worktree.sh

$grep -l "git worktree" t/*.sh
t/t0002-gitfile.sh
t/t1400-update-ref.sh
t/t2025-worktree-add.sh
t/t2026-worktree-prune.sh
t/t2027-worktree-list.sh
t/t3320-notes-merge-worktrees.sh
t/t7410-submodule-checkout-to.sh

Rename t1501, t1509 and t7409 to make it clear on first glance that they
test work tree related behavior, rather than the worktree command.

t2104, t7011 and t7012 are about the "skip-worktree" flag so that their
name should remain unchanged.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Start preparing for 2.7.2

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

Merge branch 'js/test-lib-windows-emulated-yes' into maint

The emulated "yes" command used in our test scripts has been
tweaked not to spend too much time generating unnecessary output
that is not used, to help those who test on Windows where it would
not stop until it fills the pipe buffer due to lack of SIGPIPE.

* js/test-lib-windows-emulated-yes:
  test-lib: limit the output of the yes utility

Merge branch 'aw/push-force-with-lease-reporting' into maint

"git push --force-with-lease" has been taught to report if the push
needed to force (or fast-forwarded).

* aw/push-force-with-lease-reporting:
  push: fix ref status reporting for --force-with-lease

Merge branch 'nd/do-not-move-worktree-manually' into maint

"git worktree" had a broken code that attempted to auto-fix
possible inconsistency that results from end-users moving a
worktree to different places without telling Git (the original
repository needs to maintain backpointers to its worktrees, but
"mv" run by end-users who are not familiar with that fact will
obviously not adjust them), which actually made things worse
when triggered.

* nd/do-not-move-worktree-manually:
  worktree: stop supporting moving worktrees manually
  worktree.c: fix indentation

Merge branch 'js/xmerge-marker-eol' into maint

The low-level merge machinery has been taught to use CRLF line
termination when inserting conflict markers to merged contents that
are themselves CRLF line-terminated.

* js/xmerge-marker-eol:
  merge-file: ensure that conflict sections match eol style
  merge-file: let conflict markers match end-of-line style of the context

git-cvsserver.perl: fix typo

Signed-off-by: GyuYong Jung <obliviscence@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: introduce set_or_die wrappers

A lot of call-sites for the existing family of `git_config_set`
functions do not check for errors that may occur, e.g. when the
configuration file is locked. In many cases we simply want to die
when such a situation arises.

Introduce wrappers that will cause the program to die in those
cases. These wrappers are temporary only to ease the transition
to let `git_config_set` die by default. They will be removed
later on when `git_config_set` itself has been replaced by
`git_config_set_gently`.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote-curl: include curl_errorstr on SSL setup failures

For curl error 35 (CURLE_SSL_CONNECT_ERROR) users need the
additional text stored in CURLOPT_ERRORBUFFER to debug why
the connection did not start. This is curl_errorstr inside
of http.c, so include that in the message if it is non-empty.

Sometimes HTTP response codes aren't yet available, such as
when the SSL setup fails. Don't include HTTP 0 in the message.

Signed-off-by: Shawn Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mergetool: reorder vim/gvim buffers in three-way diffs

When invoking default (g)vimdiff three-way merge, the merged file is
loaded as the first buffer but moved to the bottom as the fourth window.
This causes a disconnect between vim commands that operate on window
positions (e.g. CTRL-W_w) and those that operate on buffer index (e.g.
do/dp).

This change reorders the buffers to have the same index as windows while
keeping the cursor default to the merged result as the bottom window.

Signed-off-by: Dickson Wong <dicksonwong@gmail.com>
Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

get_sha1: don't die() on bogus search strings

The get_sha1() function generally returns an error code
rather than dying, and we sometimes speculatively call it
with something that may be a revision or a pathspec, in
order to see which one it might be.

If it sees a bogus ":/" search string, though, it complains,
without giving the caller the opportunity to recover. We can
demonstrate this in t6133 by looking for ":/*.t", which
should mean "*.t at the root of the tree", but instead dies
because of the invalid regex (the "*" has nothing to operate
on).

We can fix this by returning an error rather than calling
die(). Unfortunately, the tradeoff is that the error message
is slightly worse in cases where we _do_ know we have a rev.
E.g., running "git log ':/*.t' --" before yielded:

  fatal: Invalid search pattern: *.t

and now we get only:

  fatal: bad revision ':/*.t'

There's not a simple way to fix this short of passing a
"quiet" flag all the way through the get_sha1() stack.

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

check_filename: tighten dwim-wildcard ambiguity

When specifying both revisions and pathnames, we allow
"<rev> -- <pathspec>" to be spelled without the "--" as long
as it is not ambiguous. The original logic was something
like:

  1. Resolve each item with get_sha1(). If successful,
     we know it can be a <rev>. Verify that it _isn't_ a
     filename, using verify_non_filename(), and complain of
     ambiguity otherwise.

  2. If get_sha1() didn't succeed, make sure that it _is_
     a file, using verify_filename(). If not, complain
     that it is neither a <rev> nor a <pathspec>.

Both verify_filename() and verify_non_filename() rely on
check_filename(), which definitely said "yes, this is a
file" or "no, it is not" using lstat().

Commit 28fcc0b (pathspec: avoid the need of "--" when
wildcard is used, 2015-05-02) introduced a convenience
feature: check_filename() will consider anything with
wildcard meta-characters as a possible filename, without
even checking the filesystem.

This works well for case 2. For such a wildcard, we would
previously have died and said "it is neither". Post-28fcc0b,
we assume it's a pathspec and proceed.

But it makes some instances of case 1 worse. We may have an
extended sha1 expression that contains meta-characters
(e.g., "HEAD^{/foo.*bar}"), and we now complain that it's
also a filename, due to the wildcard characters (even though
that wildcard would not match anything in the filesystem).

One solution would be to actually expand the pathname and
see if it matches anything on the filesystem. But that's
potentially expensive, and we do not have to be so rigorous
for this DWIM magic (if you want rigor, use "--").

Instead, we can just use different rules for cases 1 and 2.
When we know something is a rev, we will complain only if it
meets a much higher standard for "this is also a file";
namely that it actually exists in the filesystem. Case 2
remains the same: we use the looser "it could be a filename"
standard introduced by 28fcc0b.

We can accomplish this by pulling the wildcard logic out of
check_filename() and putting it into verify_filename(). Its
partner verify_non_filename() does not need a change, since
check_filename() goes back to implementing the "higher
standard".

Besides these two callers of check_filename(), there is one
other: git-checkout does a similar DWIM itself. It hits this
code path only after get_sha1() has returned failure, making
it case 2, which gets the special wildcard treatment.

Note that we drop the tests in t2019 in favor of a more
complete set in t6133. t2019 was not the right place for
them (it's about refname ambiguity, not dwim parsing
ambiguity), and the second test explicitly checked for the
opposite result of the case we are fixing here (which didn't
really make any sense; as shown by the test_must_fail in the
test, it would only serve to annoy people).

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

checkout: reorder check_filename conditional

If we have a "--" flag, we should not be doing DWIM magic
based on whether arguments can be filenames. Reorder the
conditional to avoid the check_filename() call entirely in
this case. The outcome is the same, but the short-circuit
makes the dependency more clear.

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

Documentation/git-clean.txt: don't mention deletion of .git/modules/*

The latter half of this sentence, the removal of the submodules, was
never done with (or without) double -f back when it was written, and
we still do not do so.

Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.7.1

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

Merge branch 'lv/add-doc-working-tree' into maint

* lv/add-doc-working-tree:
  git-add doc: do not say working directory when you mean working tree

Merge branch 'ss/clone-depth-single-doc' into maint

Documentation for "git fetch --depth" has been updated for clarity.

* ss/clone-depth-single-doc:
  docs: clarify that --depth for git-fetch works with newly initialized repos
  docs: say "commits" in the --depth option wording for git-clone
  docs: clarify that passing --depth to git-clone implies --single-branch

Merge branch 'sg/t6050-failing-editor-test-fix' into maint

* sg/t6050-failing-editor-test-fix:
  t6050-replace: make failing editor test more robust

Merge branch 'ew/for-each-ref-doc' into maint

* ew/for-each-ref-doc:
  for-each-ref: document `creatordate` and `creator` fields

Merge branch 'ss/user-manual' into maint

Drop a few old "todo" items by deciding that the change one of them
suggests is not such a good idea, and doing the change the other
one suggested to do.

* ss/user-manual:
  user-manual: add addition gitweb information
  user-manual: add section documenting shallow clones
  glossary: define the term shallow clone
  user-manual: remove temporary branch entry from todo list

Merge branch 'jk/ref-cache-non-repository-optim' into maint

The underlying machinery used by "ls-files -o" and other commands
have been taught not to create empty submodule ref cache for a
directory that is not a submodule.  This removes a ton of wasted
CPU cycles.

* jk/ref-cache-non-repository-optim:
  resolve_gitlink_ref: ignore non-repository paths
  clean: make is_git_repository a public function

Merge branch 'js/dirname-basename' into maint

dirname() emulation has been added, as Msys2 lacks it.

* js/dirname-basename:
  mingw: avoid linking to the C library's isalpha()
  t0060: loosen overly strict expectations
  t0060: verify that basename() and dirname() work as expected
  compat/basename.c: provide a dirname() compatibility function
  compat/basename: make basename() conform to POSIX
  Refactor skipping DOS drive prefixes

Merge branch 'tb/complete-word-diff-regex' into maint

* tb/complete-word-diff-regex:
  completion: complete "diff --word-diff-regex="

Merge branch 'pw/completion-stash' into maint

* pw/completion-stash:
  completion: update completion arguments for stash

Merge branch 'pw/completion-show-branch' into maint

* pw/completion-show-branch:
  completion: complete show-branch "--date-order"

Merge branch 'jk/completion-rebase' into maint

* jk/completion-rebase:
  completion: add missing git-rebase options

Merge branch 'nd/diff-with-path-params' into maint

A few options of "git diff" did not work well when the command was
run from a subdirectory.

* nd/diff-with-path-params:
  diff: make -O and --output work in subdirectory
  diff-no-index: do not take a redundant prefix argument

Merge branch 'dw/subtree-split-do-not-drop-merge' into maint

The "split" subcommand of "git subtree" (in contrib/) incorrectly
skipped merges when it shouldn't, which was corrected.

* dw/subtree-split-do-not-drop-merge:
  contrib/subtree: fix "subtree split" skipped-merge bug

Merge branch 'ew/svn-1.9.0-auth' into maint

* ew/svn-1.9.0-auth:
  git-svn: fix auth parameter handling on SVN 1.9.0+

Merge branch 'jk/list-tag-2.7-regression' into maint

"git tag" started listing a tag "foo" as "tags/foo" when a branch
named "foo" exists in the same repository; remove this unnecessary
disambiguation, which is a regression introduced in v2.7.0.

* jk/list-tag-2.7-regression:
  tag: do not show ambiguous tag names as "tags/foo"
  t6300: use test_atom for some un-modern tests

Merge branch 'jk/sanity' into maint

The description for SANITY prerequisite the test suite uses has
been clarified both in the comment and in the implementation.

* jk/sanity:
  test-lib: clarify and tighten SANITY

Merge branch 'jk/filter-branch-no-index' into maint

A recent optimization to filter-branch in v2.7.0 introduced a
regression when --prune-empty filter is used, which has been
corrected.

* jk/filter-branch-no-index:
  filter-branch: resolve $commit^{tree} in no-index case

Merge branch 'js/close-packs-before-gc' into maint

Many codepaths that run "gc --auto" before exiting kept packfiles
mapped and left the file descriptors to them open, which was not
friendly to systems that cannot remove files that are open.  They
now close the packs before doing so.

* js/close-packs-before-gc:
  receive-pack: release pack files before garbage-collecting
  merge: release pack files before garbage-collecting
  am: release pack files before garbage-collecting
  fetch: release pack files before garbage-collecting

Merge branch 'jk/ok-to-fail-gc-auto-in-rebase' into maint

"git rebase", unlike all other callers of "gc --auto", did not
ignore the exit code from "gc --auto".

* jk/ok-to-fail-gc-auto-in-rebase:
  rebase: ignore failures from "gc --auto"

Merge branch 'ho/gitweb-squelch-undef-warning' into maint

Asking gitweb for a nonexistent commit left a warning in the server
log.

Somebody may want to follow this up with a new test, perhaps?
IIRC, we do test that no Perl warnings are given to the server log,
so this should have been caught if our test coverage were good.

* ho/gitweb-squelch-undef-warning:
  gitweb: squelch "uninitialized value" warning

Merge branch 'js/fopen-harder' into maint

Some codepaths used fopen(3) when opening a fixed path in $GIT_DIR
(e.g. COMMIT_EDITMSG) that is meant to be left after the command is
done.  This however did not work well if the repository is set to
be shared with core.sharedRepository and the umask of the previous
user is tighter.  They have been made to work better by calling
unlink(2) and retrying after fopen(3) fails with EPERM.

* js/fopen-harder:
  Handle more file writes correctly in shared repos
  commit: allow editing the commit message even in shared repos

Merge branch 'nd/exclusion-regression-fix' into maint

The ignore mechanism saw a few regressions around untracked file
listing and sparse checkout selection areas in 2.7.0; the change
that is responsible for the regression has been reverted.

* nd/exclusion-regression-fix:
  Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"

Merge branch 'dk/reflog-walk-with-non-commit' into maint

"git reflog" incorrectly assumed that all objects that used to be
at the tip of a ref must be commits, which caused it to segfault.

* dk/reflog-walk-with-non-commit:
  reflog-walk: don't segfault on non-commit sha1's in the reflog

Merge branch 'dw/signoff-doc' into maint

The documentation has been updated to hint the connection between
the '--signoff' option and DCO.

* dw/signoff-doc:
  Expand documentation describing --signoff

Merge branch 'jk/clang-pedantic' into maint

A few unportable C construct have been spotted by clang compiler
and have been fixed.

* jk/clang-pedantic:
  bswap: add NO_UNALIGNED_LOADS define
  avoid shifting signed integers 31 bits

Merge branch 'ew/send-email-mutt-alias-fix' into maint

"git send-email" was confused by escaped quotes stored in the alias
files saved by "mutt", which has been corrected.

* ew/send-email-mutt-alias-fix:
  git-send-email: do not double-escape quotes from mutt

Merge branch 'nd/dir-exclude-cleanup' into maint

The "exclude_list" structure has the usual "alloc, nr" pair of
fields to be used by ALLOC_GROW(), but clear_exclude_list() forgot
to reset 'alloc' to 0 when it cleared 'nr' to discard the managed
array.

* nd/dir-exclude-cleanup:
  dir.c: clean the entire struct in clear_exclude_list()

Merge branch 'nd/stop-setenv-work-tree' into maint

An earlier change in 2.5.x-era broke users' hooks and aliases by
exporting GIT_WORK_TREE to point at the root of the working tree,
interfering when they tried to use a different working tree without
setting GIT_WORK_TREE environment themselves.

* nd/stop-setenv-work-tree:
  Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"

test-lib: limit the output of the yes utility

On Windows, there is no SIGPIPE. A consequence of this is that the
upstream process of a pipe does not notice the death of the downstream
process until the pipe buffer is full and writing more data returns an
error. This behavior is the reason for an annoying delay during the
execution of t7610-mergetool.sh: There are a number of test cases where
'yes' is invoked upstream. Since the utility is basically an endless
loop it runs, on Windows, until the pipe buffer is full. This does take
a few seconds.

The test suite has its own implementation of 'yes'. Modify it to produce
only a limited amount of output that is sufficient for the test suite.
The amount chosen should be sufficiently high for any test case, assuming
that future test cases will not exaggerate their demands of input from
an upstream 'yes' invocation.

[j6t: commit message]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: fix ref status reporting for --force-with-lease

The --force--with-lease push option leads to less
detailed status information than --force. In particular,
the output indicates that a reference was fast-forwarded,
even when it was force-updated.

Modify the --force-with-lease ref status logic to leverage
the --force ref status logic when the "lease" conditions
are met.

Also, enhance tests to validate output status reporting.

Signed-off-by: Andrew Wheeler <awheeler@motorola.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

stripspace: call U+0020 a "space" instead of a "blank"

I couldn't find any other examples of people referring to this
character as a "blank".

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-file: ensure that conflict sections match eol style

In the previous patch, we made sure that the conflict markers themselves
match the end-of-line style of the input files. However, this still left
out the conflicting text itself: if it lacks a trailing newline, we
add one, and should add a carriage return when appropriate, too.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-file: let conflict markers match end-of-line style of the context

When merging files with CR/LF line endings, the conflict markers should
match those, lest the output file has mixed line endings.

This is particularly of interest on Windows, where some editors get
*really* confused by mixed line endings.

The original version of this patch by Beat Bolli respected core.eol, and
a subsequent improvement by this developer also respected gitattributes.
This approach was suboptimal, though: `git merge-file` was invented as a
drop-in replacement for GNU merge and as such has no problem operating
outside of any repository at all!

Another problem with the original approach was pointed out by Junio
Hamano: legacy repositories might have their text files committed using
CR/LF line endings (and core.eol and the gitattributes would give us a
false impression there). Therefore, the much superior approach is to
simply match the context's line endings, if any.

We actually do not have to look at the *entire* context at all: if the
files are all LF-only, or if they all have CR/LF line endings, it is
sufficient to look at just a *single* line to match that style. And if
the line endings are mixed anyway, it is *still* okay to imitate just a
single line's eol: we will just add to the pile of mixed line endings,
and there is nothing we can do about that.

So what we do is: we look at the line preceding the conflict, falling
back to the line preceding that in case it was the last line and had no
line ending, falling back to the first line, first in the first
post-image, then the second post-image, and finally the pre-image.
If we find consistent CR/LF (or undecided) end-of-line style, we match
that, otherwise we use LF-only line endings for the conflict markers.

Note that while it is true that there have to be at least two lines we
can look at (otherwise there would be no conflict), the same is not true
for line *endings*: the three files in question could all consist of a
single line without any line ending, each. In this case we fall back to
using LF-only.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: fix auth parameter handling on SVN 1.9.0+

For users with "store-passwords = no" set in the "[auth]" section of
their ~/.subversion/config, SVN 1.9.0+ would fail with the
following message when attempting to call svn_auth_set_parameter:

  Value is not a string (or undef) at Git/SVN/Ra.pm

Ironically, this breakage was caused by r1553823 in subversion:

  "Make svn_auth_set_parameter() usable from Perl bindings."

Since 2007 (602015e0e6ec), git-svn has used a workaround to make
svn_auth_set_parameter usable internally.  However this workaround
breaks under SVN 1.9+, which deals properly with the type mapping
and fails to recognize our workaround.

For pre-1.9.0 SVN, we continue to use the existing workaround for
the lack of proper type mapping in the bindings.

Tested under subversion 1.6.17 and 1.9.3.

I've also verified r1553823 was not backported to SVN 1.8.x:

  BRANCH=http://svn.apache.org/repos/asf/subversion/branches/1.8.x
  svn log -v $BRANCH/subversion/bindings/swig/core.i

ref: https://bugs.debian.org/797705
Cc: 797705@bugs.debian.org
Reported-by: Thierry Vignaud <thierry.vignaud@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Tested-by: Thierry Vignaud <thierry.vignaud@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tag: do not show ambiguous tag names as "tags/foo"

Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11),
git-tag has started showing tags with ambiguous names (i.e.,
when both "heads/foo" and "tags/foo" exists) as "tags/foo"
instead of just "foo". This is both:

  - pointless; the output of "git tag" includes only
    refs/tags, so we know that "foo" means the one in
    "refs/tags".

and

  - ambiguous; in the original output, we know that the line
    "foo" means that "refs/tags/foo" exists. In the new
    output, it is unclear whether we mean "refs/tags/foo" or
    "refs/tags/tags/foo".

The reason this happens is that commit b7cc53e9 switched
git-tag to use ref-filter's "%(refname:short)" output
formatting, which was adapted from for-each-ref. This more
general code does not know that we care only about tags, and
uses shorten_unambiguous_ref to get the short-name. We need
to tell it that we care only about "refs/tags/", and it
should shorten with respect to that value.

In theory, the ref-filter code could figure this out by us
passing FILTER_REFS_TAGS. But there are two complications
there:

  1. The handling of refname:short is deep in formatting
     code that does not even have our ref_filter struct, let
     alone the arguments to the filter_ref struct.

  2. In git v2.7.0, we expose the formatting language to the
     user. If we follow this path, it will mean that
     "%(refname:short)" behaves differently for "tag" versus
     "for-each-ref" (including "for-each-ref refs/tags/"),
     which can lead to confusion.

Instead, let's add a new modifier to the formatting
language, "strip", to remove a specific set of prefix
components. This fixes "git tag", and lets users invoke the
same behavior from their own custom formats (for "tag" or
"for-each-ref") while leaving ":short" with its same
consistent meaning in all places.

We introduce a test in t7004 for "git tag", which fails
without this patch. We also add a similar test in t3203 for
"git branch", which does not actually fail. But since it is
likely that "branch" will eventually use the same formatting
code, the test helps defend against future regressions.

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

completion: update completion arguments for stash

Add --all and --include-untracked to the git stash save completions.
Add --quiet to the git stash drop completions.
Update git stash branch so that the first argument expands out to the
possible branch names, and the other arguments expand to the stash
names.

Signed-off-by: Paul Wagland <paul@kungfoocoder.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: complete show-branch "--date-order"

Signed-off-by: Paul Wagland <paul@kungfoocoder.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: add missing git-rebase options

This adds the --no-* variants where those are documented in
git-rebase(1).

Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: avoid linking to the C library's isalpha()

The implementation of mingw_skip_dos_drive_prefix() calls isalpha() via
has_dos_drive_prefix(). Since the definition occurs long before isalpha()
is defined in git-compat-util.h, my build environment reports:

    CC alloc.o
In file included from git-compat-util.h:186,
                 from cache.h:4,
                 from alloc.c:12:
compat/mingw.h: In function 'mingw_skip_dos_drive_prefix':
compat/mingw.h:365: warning: implicit declaration of function 'isalpha'

Dscho does not see a similar warning in his build and suspects that
ctype.h is included somehow behind the scenes. This implies that his build
links to the C library's isalpha() and does not use git's isalpha().

To fix both the warning in my build and the inconsistency in Dscho's
build, move the function definition to mingw.c. Then it picks up git's
isalpha() because git-compat-util.h is included at the top of the file.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t6300: use test_atom for some un-modern tests

Because this script has to test so many formatters, we have
the nice "test_atom" helper, but we don't use it
consistently. Let's do so. This is shorter, gets rid of some
tests that have their "expected" setup outside of a
test_expect_success block, and lets us organize the changes
better (e.g., putting "refname:short" near "refname").

We also expand the "%(push)" tests a little to match the
"%(upstream)" ones.

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

resolve_gitlink_ref: ignore non-repository paths

When we want to look up a submodule ref, we use
get_ref_cache(path) to find or auto-create its ref cache.
But if we feed a path that isn't actually a git repository,
we blindly create the ref cache, and then may die deeper in
the code when we try to access it. This is a problem because
many callers speculatively feed us a path that looks vaguely
like a repository, and expect us to tell them when it is
not.

This patch teaches resolve_gitlink_ref to reject
non-repository paths without creating a ref_cache. This
avoids the die(), and also performs better if you have a
large number of these faux-submodule directories (because
the ref_cache lookup is linear, under the assumption that
there won't be a large number of submodules).

To accomplish this, we also break get_ref_cache into two
pieces: the lookup and auto-creation (the latter is lumped
into create_ref_cache). This lets us first cheaply ask our
cache "is it a submodule we know about?" If so, we can avoid
repeating our filesystem lookup. So lookups of real
submodules are not penalized; they examine the submodule's
.git directory only once.

The test in t3000 demonstrates a case where this improves
correctness (we used to just die). The new perf case in
p7300 shows off the speed improvement in an admittedly
pathological repository:

Test                  HEAD^               HEAD
----------------------------------------------------------------
7300.4: ls-files -o   66.97(66.15+0.87)   0.33(0.08+0.24) -99.5%

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

clean: make is_git_repository a public function

We have always had is_git_directory(), for looking at a
specific directory to see if it contains a git repo. In
0179ca7 (clean: improve performance when removing lots of
directories, 2015-06-15), we added is_git_repository() which
checks for a non-bare repository by looking at its ".git"
entry.

However, the fix in 0179ca7 needs to be applied other
places, too. Let's make this new helper globally available.
We need to give it a better name, though, to avoid confusion
with is_git_directory(). This patch does that, documents
both functions with a comment to reduce confusion, and
removes the clean-specific references in the comments.

Based-on-a-patch-by: Andreas Krey <a.krey@gmx.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

worktree: stop supporting moving worktrees manually

The current update_linked_gitdir() has a bug that can create "gitdir"
file in non-multi-worktree setup. Worse, sometimes it can write relative
path to "gitdir" file, which will not work (e.g. "git worktree list"
will display the worktree's location incorrectly)

Instead of fixing this, we step back a bit. The original design was
probably not well thought out. For now, if the user manually moves a
worktree, they have to fix up "gitdir" file manually or the worktree
will get pruned.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: make -O and --output work in subdirectory

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-no-index: do not take a redundant prefix argument

Prefix is already set up in "revs". The same prefix should be used for
all options parsing. So kill the last argument. This patch does not
actually change anything because the only caller does use the same
prefix for init_revisions() and diff_no_index().

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-add doc: do not say working directory when you mean working tree

The usage of working directory is inconsistent in the git add help.
Also http://git-scm.com/docs/git-clone speaks only about working tree.
Remaining entry found by "git grep -B1 '^directory' git-add.txt" really
relates to a directory.

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

completion: complete "diff --word-diff-regex="

Signed-off-by: Thomas Braun <thomas.braun@virtuell-zuhause.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

contrib/subtree: fix "subtree split" skipped-merge bug

'git subtree split' can incorrectly skip a merge even when both parents
act on the subtree, provided the merge results in a tree identical to
one of the parents. Fix by copying the merge if at least one parent is
non-identical, and the non-identical parent is not an ancestor of the
identical parent.

Also, add a test case which checks that a descendant remains a
descendent on the subtree in this case.

Signed-off-by: Dave Ware <davidw@realtimegenomics.com>
Reviewed-by: David A. Greene <greened@obbligato.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

filter-branch: resolve $commit^{tree} in no-index case

Commit 348d4f2 (filter-branch: skip index read/write when
possible, 2015-11-06) taught filter-branch to optimize out
the final "git write-tree" when we know we haven't touched
the tree with any of our filters. It does by simply putting
the literal text "$commit^{tree}" into the "$tree" variable,
avoiding a useless rev-parse call.

However, when we pass this to git_commit_non_empty_tree(),
it gets confused; it resolves "$commit^{tree}" itself, and
compares our string to the 40-hex sha1, which obviously
doesn't match. As a result, "--prune-empty" (or any custom
filter using git_commit_non_empty_tree) will fail to drop
an empty commit (when filter-branch is used without a tree
or index filter).

Let's resolve $tree to the 40-hex ourselves, so that
git_commit_non_empty_tree can work. Unfortunately, this is a
bit slower due to the extra process overhead:

  $ cd t/perf && ./run 348d4f2 HEAD p7000-filter-branch.sh
  [...]
  Test                  348d4f2           HEAD
  --------------------------------------------------------------
  7000.2: noop filter   3.76(0.24+0.26)   4.54(0.28+0.24) +20.7%

We could try to make git_commit_non_empty_tree more clever.
However, the value of $tree here is technically
user-visible. The user can provide arbitrary shell code at
this stage, which could itself have a similar assumption to
what is in git_commit_non_empty_tree. So the conservative
choice to fix this regression is to take the 20% hit and
give the pre-348d4f2 behavior. We still end up much faster
than before the optimization:

  $ cd t/perf && ./run 348d4f2^ HEAD p7000-filter-branch.sh
  [...]
  Test                  348d4f2^          HEAD
  --------------------------------------------------------------
  7000.2: noop filter   9.51(4.32+0.40)   4.51(0.28+0.23) -52.6%

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

test-lib: clarify and tighten SANITY

f400e51c (test-lib.sh: set prerequisite SANITY by testing what we
really need, 2015-01-27) improved the way SANITY prerequisite was
determined, but made the resulting code (incorrectly) imply that
SANITY is all about effects of permission bits of the containing
directory has on the files contained in it by the comment it added,
its log message and the actual tests.

State what SANITY is about more clearly in the comment, and test
that a file whose permission bits says should be unreadble truly
cannot be read.

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

worktree.c: fix indentation

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0060: loosen overly strict expectations

The dirname() tests file were developed and tested on only the five
platforms available to the developer at the time, namely: Linux (both 32
and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
(i.e. the POSIX spec) says, in part:

If the string pointed to by path consists entirely of the '/'
character, basename() shall return a pointer to the string "/".
If the string pointed to by path is exactly "//", it is
implementation-defined whether "/" or "//" is returned.

The thinking behind testing precise, OS-dependent output values was to
document that different setups produce different values. However, as the
test failures on MacOSX illustrated eloquently: hardcoding pretty much each
and every setup's expectations is pretty fragile.

This is not limited to the "//" vs "/" case, of course, other inputs are
also allowed to produce multiple outputs by the POSIX specs.

So let's just test for all allowed values and be done with it. This still
documents that Git cannot rely on one particular output value in those
cases, so the intention of the original tests is still met.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase: ignore failures from "gc --auto"

After rebasing, we call "gc --auto" to clean up if we
created a lot of loose objects. However, we do so inside an
&&-chain. If "gc --auto" fails (e.g., because a previous
background gc blocked us by leaving "gc.log" in place),
then:

  1. We will fail to clean up the state directory, leaving
     the user stuck in the rebase forever (even "git am
     --abort" doesn't work, because it calls "gc --auto"!).

  2. In some cases, we may return a bogus exit code from
     rebase, indicating failure when everything except the
     auto-gc succeeded.

We can fix this by ignoring the exit code of "gc --auto".

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

receive-pack: release pack files before garbage-collecting

Before auto-gc'ing, we need to make sure that the pack files are
released in case they need to be repacked and garbage-collected.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge: release pack files before garbage-collecting

Before auto-gc'ing, we need to make sure that the pack files are
released in case they need to be repacked and garbage-collected.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>