Merge branch 'rj/compat-regex-size-max-fix'

A compilation fix.

* rj/compat-regex-size-max-fix:
  regex: fix a SIZE_MAX macro redefinition warning

Merge branch 'vs/prompt-avoid-unset-variable'

The git-prompt scriptlet (in contrib/) was not friendly with those
who uses "set -u", which has been fixed.

* vs/prompt-avoid-unset-variable:
  git-prompt.sh: Don't error on null ${ZSH,BASH}_VERSION, $short_sha

Merge branch 'sg/reflog-past-root'

"git reflog" stopped upon seeing an entry that denotes a branch
creation event (aka "unborn"), which made it appear as if the
reflog was truncated.

* sg/reflog-past-root:
  reflog: continue walking the reflog past root commits

Merge branch 'pb/strbuf-read-file-doc'

* pb/strbuf-read-file-doc:
  strbuf: describe the return value of strbuf_read_file

Merge branch 'dn/gpg-doc'

The documentation tries to consistently spell "GPG"; when
referring to the specific program name, "gpg" is used.

* dn/gpg-doc:
  Documentation: GPG capitalization

Merge branch 'jk/fetch-prune-doc'

* jk/fetch-prune-doc:
  fetch: document that pruning happens before fetching

Merge branch 'ap/git-svn-propset-doc'

"git svn propset" subcommand that was added in 2.3 days is
documented now.

* ap/git-svn-propset-doc:
  git-svn: document the 'git svn propset' command

Merge branch 'tr/doc-tt'

The documentation set has been updated so that literal commands,
configuration variables and environment variables are consistently
typeset in fixed-width font and bold in manpages.

* tr/doc-tt:
  doc: change configuration variables format
  doc: more consistency in environment variables format
  doc: change environment variables format
  doc: clearer rule about formatting literals

Merge branch 'pc/occurred'

* pc/occurred:
  config.c: fix misspelt "occurred" in an error message
  refs.h: fix misspelt "occurred" in a comment

Merge branch 'cc/apply-introduce-state'

The "git apply" standalone program is being libified; this is the
first step to move many state variables into a structure that can
be explicitly (re)initialized to make the machinery callable more
than once.

The next step that moves some remaining state variables into the
structure and turns die()s into an error return that propagates up
to the caller is not queued yet but in flight.  It would be good to
review the above first and give the remainder of the series a solid
base to build on.

* cc/apply-introduce-state: (50 commits)
  builtin/apply: remove misleading comment on lock_file field
  builtin/apply: move 'newfd' global into 'struct apply_state'
  builtin/apply: add 'lock_file' pointer into 'struct apply_state'
  builtin/apply: move applying patches into apply_all_patches()
  builtin/apply: move 'state' check into check_apply_state()
  builtin/apply: move 'symlink_changes' global into 'struct apply_state'
  builtin/apply: move 'fn_table' global into 'struct apply_state'
  builtin/apply: move 'state_linenr' global into 'struct apply_state'
  builtin/apply: move 'max_change' and 'max_len' into 'struct apply_state'
  builtin/apply: move 'ws_ignore_action' into 'struct apply_state'
  builtin/apply: move 'ws_error_action' into 'struct apply_state'
  builtin/apply: move 'applied_after_fixing_ws' into 'struct apply_state'
  builtin/apply: move 'squelch_whitespace_errors' into 'struct apply_state'
  builtin/apply: remove whitespace_option arg from set_default_whitespace_mode()
  builtin/apply: move 'whitespace_option' into 'struct apply_state'
  builtin/apply: move 'whitespace_error' global into 'struct apply_state'
  builtin/apply: move 'root' global into 'struct apply_state'
  builtin/apply: move 'p_value_known' global into 'struct apply_state'
  builtin/apply: move 'p_value' global into 'struct apply_state'
  builtin/apply: move 'has_include' global into 'struct apply_state'
  ...

git-svn: skip mergeinfo handling with --no-follow-parent

For repositories without parent following enabled, finding
git parents through svn:mergeinfo or svk::parents can be
expensive and pointless.

Reported-by: Александр Овчинников <proff@proff.email>
http://mid.gmane.org/4094761466408188@web24o.yandex.ru

Signed-off-by: Eric Wong <e@80x24.org>

Start the post-2.9 cycle

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

Merge branch 'rs/xdiff-hunk-with-func-line'

"git show -W" (extend hunks to cover the entire function, delimited
by lines that match the "funcname" pattern) used to show the entire
file when a change added an entire function at the end of the file,
which has been fixed.

* rs/xdiff-hunk-with-func-line:
  xdiff: fix merging of appended hunk with -W
  grep: -W: don't extend context to trailing empty lines
  t7810: add test for grep -W and trailing empty context lines
  xdiff: don't trim common tail with -W
  xdiff: -W: don't include common trailing empty lines in context
  xdiff: ignore empty lines before added functions with -W
  xdiff: handle appended chunks better with -W
  xdiff: factor out match_func_rec()
  t4051: rewrite, add more tests

Merge branch 'jk/rev-list-count-with-bitmap'

"git rev-list --count" whose walk-length is limited with "-n"
option did not work well with the counting optimized to look at the
bitmap index.

* jk/rev-list-count-with-bitmap:
  rev-list: disable bitmaps when "-n" is used with listing objects
  rev-list: "adjust" results of "--count --use-bitmap-index -n"

Merge branch 'wd/userdiff-css'

Update the funcname definition to support css files.

* wd/userdiff-css:
  userdiff: add built-in pattern for CSS

Merge branch 'jc/clear-pathspec'

We usually call a function that clears the contents a data
structure X without freeing the structure itself clear_X(), and
call a function that does clear_X() and also frees it free_X().
free_pathspec() function has been renamed to clear_pathspec()
to avoid confusion.

* jc/clear-pathspec:
  pathspec: rename free_pathspec() to clear_pathspec()

Merge branch 'aq/upload-pack-use-parse-options'

"git upload-pack" command has been updated to use the parse-options
API.

* aq/upload-pack-use-parse-options:
  upload-pack.c: use parse-options API

Merge branch 'jg/dash-is-last-branch-in-worktree-add'

"git worktree add" learned that '-' can be used as a short-hand for
"@{-1}", the previous branch.

* jg/dash-is-last-branch-in-worktree-add:
  worktree: allow "-" short-hand for @{-1} in add command

Merge branch 'et/pretty-format-c-auto'

The commands in `git log` family take %C(auto) in a custom format
string.  This unconditionally turned the color on, ignoring
--no-color or with --color=auto when the output is not connected to
a tty; this was corrected to make the format truly behave as
"auto".

* et/pretty-format-c-auto:
  format_commit_message: honor `color=auto` for `%C(auto)`

Merge branch 'sb/submodule-recommend-shallowness'

An upstream project can make a recommendation to shallowly clone
some submodules in the .gitmodules file it ships.

* sb/submodule-recommend-shallowness:
  submodule update: learn `--[no-]recommend-shallow` option
  submodule-config: keep shallow recommendation around

Merge branch 'sb/submodule-misc-cleanups'

Minor simplification.

* sb/submodule-misc-cleanups:
  submodule update: make use of the existing fetch_in_submodule function

Merge branch 'ew/daemon-socket-keepalive'

When "git daemon" is run without --[init-]timeout specified, a
connection from a client that silently goes offline can hang around
for a long time, wasting resources.  The socket-level KEEPALIVE has
been enabled to allow the OS to notice such failed connections.

* ew/daemon-socket-keepalive:
  daemon: enable SO_KEEPALIVE for all sockets

Merge branch 'ah/no-verify-signature-with-pull-rebase'

"git pull --rebase --verify-signature" learned to warn the user
that "--verify-signature" is a no-op when rebasing.

* ah/no-verify-signature-with-pull-rebase:
  pull: warn on --verify-signatures with --rebase

Merge branch 'ew/fast-import-unpack-limit'

"git fast-import" learned the same performance trick to avoid
creating too small a packfile as "git fetch" and "git push" have,
using *.unpackLimit configuration.

* ew/fast-import-unpack-limit:
  fast-import: invalidate pack_id references after loosening
  fast-import: implement unpack limit

Documentation: GPG capitalization

When "GPG" is used in a sentence it is now consistently capitalized.
When referring to the binary it is left as "gpg".

Signed-off-by: David Nicolson <david.nicolson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: document the 'git svn propset' command

Add example usage to the git-svn documentation.

Reported-by: Joseph Pecoraro <pecoraro@apple.com>
Signed-off-by: Alfred Perlstein <alfred@freebsd.org>
Reviewed-by: Eric Wong <e@80x24.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

strbuf: describe the return value of strbuf_read_file

Mentored-by: Lars Schneider <larsxschneider@gmail.com>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch: document that pruning happens before fetching

This was changed in 10a6cc8 (fetch --prune: Run prune before
fetching, 2014-01-02), but it seems that nobody in that
discussion realized we were advertising the "after"
explicitly.

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

Git 2.9

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

Merge tag 'l10n-2.9.0-rc0' of git://github.com/git-l10n/git-po

l10n-2.9.0-rc0

* tag 'l10n-2.9.0-rc0' of git://github.com/git-l10n/git-po:
  l10n: ko.po: Update Korean translation
  l10n: ru.po: update Russian translation
  l10n: de.po: translate 104 new messages
  l10n: zh_CN: review for git v2.9.0 l10n round 1
  l10n: zh_CN: for git v2.9.0 l10n round 1
  l10n: pt_PT: update Portuguese translation
  l10n: pt_PT: update according to git-gui glossary
  l10n: pt_PT: merge git.pot file
  l10n: Updated Bulgarian translation of git (2597t,0f,0u)
  l10n: sv.po: Update Swedish translation (2597t0f0u)
  l10n: fr.po v2.9.0rnd1
  l10n: Updated Vietnamese translation (2597t)
  l10n: git.pot: v2.9.0 round 1 (104 new, 37 removed)
  l10n: fr.po Fixed grammar mistake

l10n: ko.po: Update Korean translation

Merge branch 'russian-l10n' of https://github.com/DJm00n/git-po-ru

* 'russian-l10n' of https://github.com/DJm00n/git-po-ru:
  l10n: ru.po: update Russian translation

l10n: ru.po: update Russian translation

Signed-off-by: Dimitriy Ryazantcev <dimitriy.ryazantcev@gmail.com>

Hopefully the final last-minute update before 2.9 final

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

Merge branch 'jk/diff-compact-heuristic'

It turns out that the earlier effort to update the heuristics may
want to use a bit more time to mature.  Turn it off by default.

* jk/diff-compact-heuristic:
  diff: disable compaction heuristic for now

Merge branch 'jk/shell-portability'

test fixes.

* jk/shell-portability:
  t5500 & t7403: lose bash-ism "local"
  test-lib: add in-shell "env" replacement

Merge branch 'jc/t2300-setup'

A test fix.

* jc/t2300-setup:
  t2300: run git-sh-setup in an environment that better mimics the real life

config.c: fix misspelt "occurred" in an error message

Signed-off-by: Peter Colberg <peter@colberg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

refs.h: fix misspelt "occurred" in a comment

Signed-off-by: Peter Colberg <peter@colberg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff: disable compaction heuristic for now

http://lkml.kernel.org/g/20160610075043.GA13411@sigill.intra.peff.net
reports that a change to add a new "function" with common ending
with the existing one at the end of the file is shown like this:

    def foo
      do_foo_stuff()

   +  common_ending()
   +end
   +
   +def bar
   +  do_bar_stuff()
   +
      common_ending()
    end

when the new heuristic is in use.  In reality, the change is to add
the blank line before "def bar" and everything below, which is what
the code without the new heuristic shows.

Disable the heuristics by default, and resurrect the documentation
for the option and the configuration variables, while clearly
marking the feature as still experimental.

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

l10n: de.po: translate 104 new messages

Translate 104 new messages came from git.pot update in f517e50
(l10n: git.pot: v2.9.0 round 1 (104 new, 37 removed)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>

xdiff: fix merging of appended hunk with -W

When -W is given we search the lines between the end of the current
context and the next change for a function line.  If there is none then
we merge those two hunks as they must be part of the same function.

If the next change is an appended chunk we abort the search early in
get_func_line(), however, because its line number is out of range.  Fix
that by searching from the end of the pre-image in that case instead.

Reported-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: zh_CN: review for git v2.9.0 l10n round 1

Signed-off-by: Ray Chen <oldsharp@gmail.com>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

doc: change configuration variables format

This change configuration variables that where in italic style
to monospace font according to the guideline. It was obtained with

grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \
sed -e 's/::$//' -e 's/\./\\\\./' | \
xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt

Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: more consistency in environment variables format

Wrap with backticks (monospaced font) unwrapped or single-quotes wrapped
(italic type) environment variables which are followed by the word
"environment". It was obtained with:

perl -pi -e "s/\'?(\\\$?[0-9A-Z\_]+)\'?(?= environment ?)/\`\1\`/g" *.txt

One of the main purposes is to stick to the CodingGuidelines as possible so
that people writting new documentation by mimicking the existing are more likely
to have it right (even if they didn't read the CodingGuidelines).

Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: change environment variables format

This change GIT_* variables that where in italic style to monospaced font
according to the guideline. It was obtained with

perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt

One of the main purposes is to stick to the CodingGuidelines as possible so
that people writting new documentation by mimicking the existing are more likely
to have it right (even if they didn't read the CodingGuidelines).

Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: clearer rule about formatting literals

Make the guideline text that we want for our documentation clearer.

Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

regex: fix a SIZE_MAX macro redefinition warning

Since commit 56a1a3ab ("Silence GCC's \"cast of pointer to integer of a
different size\" warning", 26-10-2015), sparse has been issuing a macro
redefinition warning for the SIZE_MAX macro. However, gcc did not issue
any such warning.

After commit 56a1a3ab, in terms of the order of #includes and #defines,
the code looked something like:

  $ cat -n junk.c
       1 #include <stddef.h>
       2
       3 #define SIZE_MAX ((size_t) -1)
       4
       5 #include <stdint.h>
       6
       7 int main(int argc, char *argv[])
       8 {
       9 return 0;
      10 }
  $
  $ gcc junk.c
  $

However, if you compile that file with -Wsystem-headers, then it will
also issue a warning. Having set -Wsystem-headers in CFLAGS, using the
config.mak file, then (on cygwin):

  $ make compat/regex/regex.o
      CC compat/regex/regex.o
  In file included from /usr/lib/gcc/x86_64-pc-cygwin/4.9.3/include/stdint.h:9:0,
                   from compat/regex/regcomp.c:21,
                   from compat/regex/regex.c:77:
  /usr/include/stdint.h:362:0: warning: "SIZE_MAX" redefined
   #define SIZE_MAX (__SIZE_MAX__)
   ^
  In file included from compat/regex/regex.c:69:0:
  compat/regex/regex_internal.h:108:0: note: this is the location of the previous definition
   # define SIZE_MAX ((size_t) -1)
   ^
  $

The compilation of the compat/regex code is somewhat unusual in that the
regex.c file directly #includes the other c files (regcomp.c, regexec.c
and regex_internal.c). Commit 56a1a3ab added an #include of <stdint.h>
to the regcomp.c file, which results in the redefinition, since this is
included after the regex_internal.h header. This header file contains a
'fallback' definition for SIZE_MAX, in order to support systems which do
not have the <stdint.h> header (the HAVE_STDINT_H macro is not defined).

In order to suppress the warning, we move the #include of <stdint.h>
from regcomp.c to the start of the compilation unit, close to the top
of regex.c, prior to the #include of the regex_internal.h header.

Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

reflog: continue walking the reflog past root commits

If a repository contains more than one root commit, then its HEAD
reflog may contain multiple "creation events", i.e. entries whose
"from" value is the null sha1.  Listing such a reflog currently stops
prematurely at the first such entry, even when the reflog still
contains older entries.  This can scare users into thinking that their
reflog got truncated after 'git checkout --orphan'.

Continue walking the reflog past such creation events based on the
preceeding reflog entry's "new" value.

The test 'symbolic-ref writes reflog entry' in t1401-symbolic-ref
implicitly relies on the current behavior of the reflog walker to stop
at a root commit and thus to list only the reflog entries that are
relevant for that test.  Adjust the test to explicitly specify the
number of relevant reflog entries to be listed.

Reported-by: Patrik Gustafsson <pvn@textalk.se>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.9-rc2

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

Sync with 2.8.4

* maint:
  Git 2.8.4

Git 2.8.4

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

Merge branch 'kb/msys2-tty' into maint

The "are we talking with TTY, doing an interactive session?"
detection has been updated to work better for "Git for Windows".

* kb/msys2-tty:
  mingw: make isatty() recognize MSYS2's pseudo terminals (/dev/pty*)

Merge branch 'da/difftool' into maint

"git difftool" learned to handle unmerged paths correctly in
dir-diff mode.

* da/difftool:
  difftool: handle unmerged files in dir-diff mode
  difftool: initialize variables for readability

Merge branch 'tb/core-eol-fix' into maint

A couple of bugs around core.autocrlf have been fixed.

* tb/core-eol-fix:
  convert.c: ident + core.autocrlf didn't work
  t0027: test cases for combined attributes
  convert: allow core.autocrlf=input and core.eol=crlf
  t0027: make commit_chk_wrnNNO() reliable

Merge branch 'ar/diff-args-osx-precompose' into maint

Many commands normalize command line arguments from NFD to NFC
variant of UTF-8 on OSX, but commands in the "diff" family did
not, causing "git diff $path" to complain that no such path is
known to Git.  They have been taught to do the normalization.

* ar/diff-args-osx-precompose:
  diff: run arguments through precompose_argv

Merge branch 'sb/submodule-helper-relative-path'

A bash-ism "local" has been removed from "git submodule" scripted
Porcelain.

* sb/submodule-helper-relative-path:
  submodule: remove bashism from shell script

Merge branch 'sb/submodule-helper-list-signal-unmatch-via-exit-status'

The way how "submodule--helper list" signals unmatch error to its
callers has been updated.

* sb/submodule-helper-list-signal-unmatch-via-exit-status:
  submodule--helper: offer a consistent API

builtin/apply: remove misleading comment on lock_file field

Just like pointer field like prefix, the piece of memory pointed at
by lock_file field is not owned by the apply_state structure.  It is
true that the caller needs to be careful about the lifetime rule for
lockfile instances, but that is none of this API's business.

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

git-prompt.sh: Don't error on null ${ZSH,BASH}_VERSION, $short_sha

When the shell is in "nounset" or "set -u" mode, referencing unset or
null variables results in an error. Protect $ZSH_VERSION and
$BASH_VERSION against that, and initialize $short_sha before use.

Signed-off-by: Ville Skyttä <ville.skytta@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: zh_CN: for git v2.9.0 l10n round 1

Update 104 new translations (2596t1f0u) for git v2.9.0-rc0.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

userdiff: add built-in pattern for CSS

CSS is widely used, motivating it being included as a built-in pattern.

It must be noted that the word_regex for CSS (i.e. the regex defining
what is a word in the language) does not consider '.' and '#' characters
(in CSS selectors) to be part of the word. This behavior is documented
by the test t/t4018/css-rule.
The logic behind this behavior is the following: identifiers in CSS
selectors are identifiers in a HTML/XML document. Therefore, the '.'/'#'
character are not part of the identifier, but an indicator of the nature
of the identifier in HTML/XML (class or id). Diffing ".class1" and
".class2" must show that the class name is changed, but we still are
selecting a class.

Logic behind the "pattern" regex is:
    1. reject lines ending with a colon/semicolon (properties)
    2. if a line begins with a name in column 1, pick the whole line

Credits to Johannes Sixt (j6t@kdbg.org) for the pattern regex and most
of the tests.

Signed-off-by: William Duclot <william.duclot@ensimag.grenoble-inp.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Almost ready for 2.9-rc2

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

Merge branch 'rs/apply-name-terminate'

Code clean-up.

* rs/apply-name-terminate:
  apply: remove unused parameters from name_terminate()

Merge branch 'rs/patch-id-use-skip-prefix'

Code clean-up.

* rs/patch-id-use-skip-prefix:
  patch-id: use starts_with() and skip_prefix()

Merge branch 'bd/readme.markdown-more'

The mark-up in the top-level README.md file has been updated to
typeset CLI command names differently from the body text.

* bd/readme.markdown-more:
  README.md: format CLI commands with code syntax

Merge branch 'mm/makefile-developer-can-be-in-config-mak'

"make DEVELOPER=1" worked as expected; setting DEVELOPER=1 in
config.mak didn't.

* mm/makefile-developer-can-be-in-config-mak:
  Makefile: add $(DEVELOPER_CFLAGS) variable
  Makefile: move 'ifdef DEVELOPER' after config.mak* inclusion

Merge branch 'em/man-bold-literal'

The manpage output of our documentation did not render well in
terminal; typeset literals in bold by default to make them stand
out more.

* em/man-bold-literal:
  Documentation: bold literals in man

Merge branch 'pa/cherry-pick-doc-typo'

"git cherry-pick --help" had three instances of word "behavior",
one of which was spelled "behaviour", which is updated to match the
other two.

* pa/cherry-pick-doc-typo:
  git-cherry-pick.txt: correct a small typo

Merge branch 'mr/send-email-doc-gmail-2fa'

Typofix.

* mr/send-email-doc-gmail-2fa:
  Documentation/git-send-email: fix typo in gmail 2FA section

Merge branch 'js/rebase-i-dedup-call-to-rerere'

"git rebase -i", after it fails to auto-resolve the conflict, had
an unnecessary call to "git rerere" from its very early days, which
was spotted recently; the call has been removed.

* js/rebase-i-dedup-call-to-rerere:
  rebase -i: remove an unnecessary 'rerere' invocation

Merge branch 'js/perf-rebase-i'

The one in 'master' has a brown-paper-bag bug that breaks the perf
test when used inside a usual Git repository with a working tree.

* js/perf-rebase-i:
  perf: make the tests work without a worktree

builtin/apply: move 'newfd' global into 'struct apply_state'

To libify the apply functionality the 'newfd' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: add 'lock_file' pointer into 'struct apply_state'

We cannot have a 'struct lock_file' allocated on the stack, as lockfile.c
keeps a linked list of all created lock_file structures.

Also 'struct apply_state' users might later want the same 'struct lock_file'
instance to be reused by different series of calls to the apply api.

So let's add a 'struct lock_file *lock_file' pointer into 'struct apply_state'
and have the user of 'struct apply_state' allocate memory for the actual
'struct lock_file' instance.

Let's also add an argument to init_apply_state(), so that the caller can
easily supply a pointer to the allocated instance.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rev-list: disable bitmaps when "-n" is used with listing objects

You can ask rev-list to use bitmaps to speed up an --objects
traversal, which should generally give you your answers much
faster.

Likewise, you can ask rev-list to limit such a traversal
with `-n`, in which case we'll show only a limited set of
commits (and only the tree and commit objects directly
reachable from those commits).

But if you do both together, the results are nonsensical. We
end up limiting any fallback traversal we do to _find_ the
bitmaps, but the actual set of objects we output will be
picked arbitrarily from the union of any bitmaps we do find,
and will involve the objects of many more commits.

It's possible that somebody might want this as a "show me
what you can, but limit the amount of work you do" flag.
But as with the prior commit clamping "--count", the results
are basically non-deterministic; you'll get the values from
some commits between `n` and the total number, and you can't
tell which.

And unlike the `--count` case, we can't easily generate the
"real" value from the bitmap values (you can't just walk
back `-n` commits and subtract out the reachable objects
from the boundary commits; the bitmaps for `X` record its
total reachability, so you don't know which objects are
directly from `X` itself, which from `X^`, and so on).

So let's just fallback to the non-bitmap code path in this
case, so we always give a sane answer.

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

rev-list: "adjust" results of "--count --use-bitmap-index -n"

If you ask rev-list for:

    git rev-list --count --use-bitmap-index HEAD

we optimize out the actual traversal and just give you the
number of bits set in the commit bitmap. This is faster,
which is good.

But if you ask to limit the size of the traversal, like:

    git rev-list --count --use-bitmap-index -n 100 HEAD

we'll still output the full bitmapped number we found. On
the surface, that might even seem OK. You explicitly asked
to use the bitmap index, and it was cheap to compute the
real answer, so we gave it to you.

But there's something much more complicated going on under
the hood. If we don't have a bitmap directly for HEAD, then
we have to actually traverse backwards, looking for a
bitmapped commit. And _that_ traversal is bounded by our
`-n` count.

This is a good thing, because it bounds the work we have to
do, which is probably what the user wanted by asking for
`-n`. But now it makes the output quite confusing. You might
get many values:

  - your `-n` value, if we walked back and never found a
    bitmap (or fewer if there weren't that many commits)

  - the actual full count, if we found a bitmap root for
    every path of our traversal with in the `-n` limit

  - any number in between! We might have walked back and
    found _some_ bitmaps, but then cut off the traversal
    early with some commits not accounted for in the result.

So you cannot even see a value higher than your `-n` and say
"OK, bitmaps kicked in, this must be the real full count".
The only sane thing is for git to just clamp the value to a
maximum of the `-n` value, which means we should output the
exact same results whether bitmaps are in use or not.

The test in t5310 demonstrates this by using `-n 1`.
Without this patch we fail in the full-bitmap case (where we
do not have to traverse at all) but _not_ in the
partial-bitmap case (where we have to walk down to find an
actual bitmap). With this patch, both cases just work.

I didn't implement the crazy in-between case, just because
it's complicated to set up, and is really a subset of the
full-count case, which we do cover.

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

pathspec: rename free_pathspec() to clear_pathspec()

The function takes a pointer to a pathspec structure, and releases
the resources held by it, but does not free() the structure itself.
Such a function should be called "clear", not "free".

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

Documentation/git-send-email: fix typo in gmail 2FA section

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

t2300: run git-sh-setup in an environment that better mimics the real life

When we run scripted Porcelains, "git" potty has set up the $PATH by
prepending $GIT_EXEC_PATH, the path given by "git --exec-path=$there
$cmd", etc. already.  Because of this, scripted Porcelains can
dot-source shell script library like git-sh-setup with simple dot
without specifying any path.

t2300 however dot-sources git-sh-setup without adjusting $PATH like
the real "git" potty does.  This has not been a problem so far, but
once git-sh-setup wants to rely on the $PATH adjustment, just like
any scripted Porcelains already do, it would become one.  It cannot
for example dot-source another shell library without specifying the
full path to it by prefixing $(git --exec-path).

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

t5500 & t7403: lose bash-ism "local"

In t5500::check_prot_host_port_path(), diagport is not a variable
used elsewhere and the function is not recursively called so this
can simply lose the "local", which may not be supported by shell
(besides, the function liberally clobbers other variables without
making them "local").

t7403::reset_submodule_urls() overrides the "root" variable used
in the test framework for no good reason; its use is not about
temporarily relocating where the test repositories are created.
This assignment can be made not to clobber the variable by moving
them into the subshells it already uses.  Its value is always
$TRASH_DIRECTORY, so we could use it instead there, and this
function that is called only once and its two subshells may not be
necessary (instead, the caller can use "git -C $there config" and
set a value that is derived from $TRASH_DIRECTORY), but this is a
minimum fix that is needed to lose "local".

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

submodule: remove bashism from shell script

Junio pointed out `relative_path` was using bashisms via the
local variables. As the longer term goal is to rewrite most of the
submodule code in C, do it now.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule--helper: offer a consistent API

In 48308681 (2016-02-29, git submodule update: have a dedicated helper
for cloning), the helper communicated errors back only via exit code,
and dance with printing '#unmatched' in case of error was left to
git-submodule.sh as it uses the output of the helper and pipes it into
shell commands. This change makes the helper consistent by never
printing '#unmatched' in the helper but always handling these piping
issues in the actual shell script.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move applying patches into apply_all_patches()

To libify the apply functionality we should provide a function to
apply many patches. Let's move the code to do that into a new
apply_all_patches() function.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'state' check into check_apply_state()

To libify the apply functionality we should provide a function
to check that the values in a 'struct apply_state' instance are
coherent. Let's move the code to do that into a new
check_apply_state() function.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'symlink_changes' global into 'struct apply_state'

To libify the apply functionality the 'symlink_changes' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'fn_table' global into 'struct apply_state'

To libify the apply functionality the 'fn_table' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

As fn_table is cleared at the end of apply_patch(), it is not
necessary to clear it in clear_apply_state().

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'state_linenr' global into 'struct apply_state'

To libify the apply functionality the 'state_linenr' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'max_change' and 'max_len' into 'struct apply_state'

To libify the apply functionality the 'max_change' and 'max_len'
variables should not be static and global to the file. Let's move
them into 'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'ws_ignore_action' into 'struct apply_state'

To libify the apply functionality the 'ws_ignore_action' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'ws_error_action' into 'struct apply_state'

To libify the apply functionality the 'ws_error_action' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'applied_after_fixing_ws' into 'struct apply_state'

To libify the apply functionality the 'applied_after_fixing_ws' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'squelch_whitespace_errors' into 'struct apply_state'

To libify the apply functionality the 'squelch_whitespace_errors' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: remove whitespace_option arg from set_default_whitespace_mode()

A previous change has move the whitespace_option variable from cmd_apply
into 'struct apply_state', so that we can now avoid passing it separately
to set_default_whitespace_mode().

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'whitespace_option' into 'struct apply_state'

This will enable further refactoring, and it is more coherent and
simpler if all the option_parse_*() functions are passed a
'struct apply_state' instance in opt->value.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'whitespace_error' global into 'struct apply_state'

To libify the apply functionality the 'whitespace_error' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'root' global into 'struct apply_state'

To libify the apply functionality the 'root' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'p_value_known' global into 'struct apply_state'

To libify the apply functionality the 'p_value_known' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'p_value' global into 'struct apply_state'

To libify the apply functionality the 'p_value' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'has_include' global into 'struct apply_state'

To libify the apply functionality the 'has_include' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

builtin/apply: move 'limit_by_name' global into 'struct apply_state'

To libify the apply functionality the 'limit_by_name' variable should
not be static and global to the file. Let's move it into
'struct apply_state'.

Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>