Merge branch 'dt/tree-fsck'

The codepath in "git fsck" to detect malformed tree objects has
been updated not to die but keep going after detecting them.

* dt/tree-fsck:
  fsck: handle bad trees like other errors
  tree-walk: be more specific about corrupt tree errors

Merge branch 'kd/mailinfo-quoted-string'

An author name, that spelled a backslash-quoted double quote in the
human readable part "My \"double quoted\" name", was not unquoted
correctly while applying a patch from a piece of e-mail.

* kd/mailinfo-quoted-string:
  mailinfo: unescape quoted-pair in header fields
  t5100-mailinfo: replace common path prefix with variable

Merge branch 'mh/diff-indent-heuristic'

Clean-up for a recently graduated topic.

* mh/diff-indent-heuristic:
  xdiff: rename "struct group" to "struct xdlgroup"

Merge branch 'dt/mailinfo'

* dt/mailinfo:
  add David Turner's Two Sigma address

Merge branch 'va/git-gui-i18n'

"git gui" l10n to Portuguese.

* va/git-gui-i18n:
  git-gui: l10n: add Portuguese translation
  git-gui i18n: mark strings for translation

Merge branch 'rs/git-gui-use-modern-git-merge-syntax'

The original command line syntax for "git merge", which was "git
merge <msg> HEAD <parent>...", has been deprecated for quite some
time, and "git gui" was the last in-tree user of the syntax.  This
is finally fixed, so that we can move forward with the deprecation.

* rs/git-gui-use-modern-git-merge-syntax:
  git-gui: stop using deprecated merge syntax

Merge branch 'jc/verify-loose-object-header'

Codepaths that read from an on-disk loose object were too loose in
validating what they are reading is a proper object file and
sometimes read past the data they read from the disk, which has
been corrected.  H/t to Gustavo Grieco for reporting.

* jc/verify-loose-object-header:
  unpack_sha1_header(): detect malformed object header
  streaming: make sure to notice corrupt object

Merge branch 'nd/init-core-worktree-in-multi-worktree-world'

"git init" tried to record core.worktree in the repository's
'config' file when GIT_WORK_TREE environment variable was set and
it was different from where GIT_DIR appears as ".git" at its top,
but the logic was faulty when .git is a "gitdir:" file that points
at the real place, causing trouble in working trees that are
managed by "git worktree".  This has been corrected.

* nd/init-core-worktree-in-multi-worktree-world:
  init: kill git_link variable
  init: do not set unnecessary core.worktree
  init: kill set_git_dir_init()
  init: call set_git_dir_init() from within init_db()
  init: correct re-initialization from a linked worktree

Merge branch 'ik/gitweb-force-highlight'

"gitweb" can spawn "highlight" to show blob contents with
(programming) language-specific syntax highlighting, but only
when the language is known.  "highlight" can however be told
to make the guess itself by giving it "--force" option, which
has been enabled.

* ik/gitweb-force-highlight:
  gitweb: use highlight's shebang detection
  gitweb: remove unused guess_file_syntax() parameter

Merge branch 'rs/copy-array'

Code cleanup.

* rs/copy-array:
  use COPY_ARRAY
  add COPY_ARRAY

Sync with maint

* maint:
  Prepare for 2.10.1

Sixth batch for 2.11

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

Merge branch 'jc/worktree-config'

"git worktree", even though it used the default_abbrev setting that
ought to be affected by core.abbrev configuration variable, ignored
the variable setting.  The command has been taught to read the
default set of configuration variables to correct this.

* jc/worktree-config:
  worktree: honor configuration variables

Merge branch 'jk/ident-ai-canonname-could-be-null'

In the codepath that comes up with the hostname to be used in an
e-mail when the user didn't tell us, we looked at ai_canonname
field in struct addrinfo without making sure it is not NULL first.

* jk/ident-ai-canonname-could-be-null:
  ident: handle NULL ai_canonname

Merge branch 'jt/fetch-pack-in-vain-count-with-stateless'

When "git fetch" tries to find where the history of the repository
it runs in has diverged from what the other side has, it has a
mechanism to avoid digging too deep into irrelevant side branches.
This however did not work well over the "smart-http" transport due
to a design bug, which has been fixed.

* jt/fetch-pack-in-vain-count-with-stateless:
  fetch-pack: do not reset in_vain on non-novel acks

Merge branch 'jk/verify-packfile-gently'

A low-level function verify_packfile() was meant to show errors
that were detected without dying itself, but under some conditions
it didn't and died instead, which has been fixed.

* jk/verify-packfile-gently:
  verify_packfile: check pack validity before accessing data

Merge branch 'jt/mailinfo-fold-in-body-headers'

When "git format-patch --stdout" output is placed as an in-body
header and it uses the RFC2822 header folding, "git am" failed to
put the header line back into a single logical line.  The
underlying "git mailinfo" was taught to handle this properly.

* jt/mailinfo-fold-in-body-headers:
  mailinfo: handle in-body header continuations
  mailinfo: make is_scissors_line take plain char *
  mailinfo: separate in-body header processing

Prepare for 2.10.1

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

Merge branch 'tg/add-chmod+x-fix' into maint

"git add --chmod=+x <pathspec>" added recently only toggled the
executable bit for paths that are either new or modified. This has
been corrected to flip the executable bit for all paths that match
the given pathspec.

* tg/add-chmod+x-fix:
  t3700-add: do not check working tree file mode without POSIXPERM
  t3700-add: create subdirectory gently
  add: modify already added files when --chmod is given
  read-cache: introduce chmod_index_entry
  update-index: add test for chmod flags

Merge branch 'et/add-chmod-x' into maint

"git add --chmod=+x" added recently lacked documentation, which has
been corrected.

* et/add-chmod-x:
  add: document the chmod option

Merge branch 'rt/rebase-i-broken-insn-advise' into maint

When "git rebase -i" is given a broken instruction, it told the
user to fix it with "--edit-todo", but didn't say what the step
after that was (i.e. "--continue").

* rt/rebase-i-broken-insn-advise:
  rebase -i: improve advice on bad instruction lines

Merge branch 'ls/travis-homebrew-path-fix' into maint

The procedure to build Git on Mac OS X for Travis CI hardcoded the
internal directory structure we assumed HomeBrew uses, which was a
no-no.  The procedure has been updated to ask HomeBrew things we
need to know to fix this.

* ls/travis-homebrew-path-fix:
  travis-ci: ask homebrew for its path instead of hardcoding it

Merge branch 'js/regexec-buf' into maint

Some codepaths in "git diff" used regexec(3) on a buffer that was
mmap(2)ed, which may not have a terminating NUL, leading to a read
beyond the end of the mapped region.  This was fixed by introducing
a regexec_buf() helper that takes a <ptr,len> pair with REG_STARTEND
extension.

* js/regexec-buf:
  regex: use regexec_buf()
  regex: add regexec_buf() that can work on a non NUL-terminated string
  regex: -G<pattern> feeds a non NUL-terminated string to regexec() and fails

Merge branch 'nd/checkout-disambiguation' into maint

"git checkout <word>" does not follow the usual disambiguation
rules when the <word> can be both a rev and a path, to allow
checking out a branch 'foo' in a project that happens to have a
file 'foo' in the working tree without having to disambiguate.
This was poorly documented and the check was incorrect when the
command was run from a subdirectory.

* nd/checkout-disambiguation:
  checkout: fix ambiguity check in subdir
  checkout.txt: document a common case that ignores ambiguation rules
  checkout: add some spaces between code and comment

Merge branch 'ep/doc-check-ref-format-example' into maint

A shell script example in check-ref-format documentation has been
fixed.

* ep/doc-check-ref-format-example:
  git-check-ref-format.txt: fixup documentation

Merge branch 'mm/config-color-ui-default-to-auto' into maint

Documentation for individual configuration variables to control use
of color (like `color.grep`) said that their default value is
'false', instead of saying their default is taken from `color.ui`.
When we updated the default value for color.ui from 'false' to
'auto' quite a while ago, all of them broke.  This has been
corrected.

* mm/config-color-ui-default-to-auto:
  Documentation/config: default for color.* is color.ui

Merge branch 'jk/reduce-gc-aggressive-depth' into maint

"git gc --aggressive" used to limit the delta-chain length to 250,
which is way too deep for gaining additional space savings and is
detrimental for runtime performance.  The limit has been reduced to
50.

* jk/reduce-gc-aggressive-depth:
  gc: default aggressive depth to 50

Merge branch 'jk/rebase-i-drop-ident-check' into maint

Even when "git pull --rebase=preserve" (and the underlying "git
rebase --preserve") can complete without creating any new commit
(i.e. fast-forwards), it still insisted on having a usable ident
information (read: user.email is set correctly), which was less
than nice.  As the underlying commands used inside "git rebase"
would fail with a more meaningful error message and advice text
when the bogus ident matters, this extra check was removed.

* jk/rebase-i-drop-ident-check:
  rebase-interactive: drop early check for valid ident

Merge branch 'jt/format-patch-base-info-above-sig' into maint

"git format-patch --base=..." feature that was recently added
showed the base commit information after "-- " e-mail signature
line, which turned out to be inconvenient.  The base information
has been moved above the signature line.

* jt/format-patch-base-info-above-sig:
  format-patch: show base info before email signature

Merge branch 'ks/perf-build-with-autoconf' into maint

Performance tests done via "t/perf" did not use the same set of
build configuration if the user relied on autoconf generated
configuration.

* ks/perf-build-with-autoconf:
  t/perf/run: copy config.mak.autogen & friends to build area

Merge branch 'rs/xdiff-merge-overlapping-hunks-for-W-context' into maint

"git diff -W" output needs to extend the context backward to
include the header line of the current function and also forward to
include the body of the entire current function up to the header
line of the next one.  This process may have to merge to adjacent
hunks, but the code forgot to do so in some cases.

* rs/xdiff-merge-overlapping-hunks-for-W-context:
  xdiff: fix merging of hunks with -W context and -u context

Merge branch 'ew/http-do-not-forget-to-call-curl-multi-remove-handle' into maint

The http transport (with curl-multi option, which is the default
these days) failed to remove curl-easy handle from a curlm session,
which led to unnecessary API failures.

* ew/http-do-not-forget-to-call-curl-multi-remove-handle:
  http: always remove curl easy from curlm session on release
  http: consolidate #ifdefs for curl_multi_remove_handle
  http: warn on curl_multi_add_handle failures

Merge branch 'jk/patch-ids-no-merges' into maint

"git log --cherry-pick" used to include merge commits as candidates
to be matched up with other commits, resulting a lot of wasted time.
The patch-id generation logic has been updated to ignore merges to
avoid the wastage.

* jk/patch-ids-no-merges:
  patch-ids: refuse to compute patch-id for merge commit
  patch-ids: turn off rename detection

Merge branch 'js/git-gui-commit-gpgsign' into maint

"git commit-tree" stopped reading commit.gpgsign configuration
variable that was meant for Porcelain "git commit" in Git 2.9; we
forgot to update "git gui" to look at the configuration to match
this change.

* js/git-gui-commit-gpgsign:
  git-gui: respect commit.gpgsign again

Merge branch 'jk/fix-remote-curl-url-wo-proto' into maint

"git fetch http::/site/path" did not die correctly and segfaulted
instead.

* jk/fix-remote-curl-url-wo-proto:
  remote-curl: handle URLs without protocol

Merge branch 'sy/git-gui-i18n-ja' into maint

Update Japanese translation for "git-gui".

* sy/git-gui-i18n-ja:
  git-gui: update Japanese information
  git-gui: update Japanese translation
  git-gui: add Japanese language code
  git-gui: apply po template to Japanese translation
  git-gui: consistently use the same word for "blame" in Japanese
  git-gui: consistently use the same word for "remote" in Japanese

Merge branch 'mr/vcs-svn-printf-ulong' into maint

Code cleanup.

* mr/vcs-svn-printf-ulong:
  vcs-svn/fast_export: fix timestamp fmt specifiers

Merge branch 'rs/unpack-trees-reduce-file-scope-global' into maint

Code cleanup.

* rs/unpack-trees-reduce-file-scope-global:
  unpack-trees: pass checkout state explicitly to check_updates()

Merge branch 'rs/strbuf-remove-fix' into maint

Code cleanup.

* rs/strbuf-remove-fix:
  strbuf: use valid pointer in strbuf_remove()

Merge branch 'rs/checkout-some-states-are-const' into maint

Code cleanup.

* rs/checkout-some-states-are-const:
  checkout: constify parameters of checkout_stage() and checkout_merged()

Merge branch 'bw/pathspec-remove-unused-extern-decl' into maint

Code cleanup.

* bw/pathspec-remove-unused-extern-decl:
  pathspec: remove unnecessary function prototypes

mailinfo: unescape quoted-pair in header fields

rfc2822 has provisions for quoted strings in structured header fields,
but also allows for escaping these with so-called quoted-pairs.

The only thing git currently does is removing exterior quotes, but
quotes within are left alone.

Remove exterior quotes and remove escape characters so that they don't
show up in the author field.

Signed-off-by: Kevin Daudt <me@ikke.info>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5100-mailinfo: replace common path prefix with variable

Many tests need to store data in a file, and repeat the same pattern to
refer to that path:

    "$TEST_DIRECTORY"/t5100/

Create a variable that contains this path, and use that instead.

While we're making this change, make sure the quotes are not just around
the variable, but around the entire string to not give the impression
we want shell splitting to affect the other variables.

Signed-off-by: Kevin Daudt <me@ikke.info>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fsck: handle bad trees like other errors

Instead of dying when fsck hits a malformed tree object, log the error
like any other and continue.  Now fsck can tell the user which tree is
bad, too.

Signed-off-by: David Turner <dturner@twosigma.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tree-walk: be more specific about corrupt tree errors

When the tree-walker runs into an error, it just calls
die(), and the message is always "corrupt tree file".
However, we are actually covering several cases here; let's
give the user a hint about what happened.

Let's also avoid using the word "corrupt", which makes it
seem like the data bit-rotted on disk. Our sha1 check would
already have found that. These errors are ones of data that
is malformed in the first place.

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

worktree: honor configuration variables

The command accesses default_abbrev (defined in environment.c and is
updated via core.abbrev configuration), but never makes any call to
git_config().  The output from "worktree list" ignores the abbrev
setting for this reason.

Make a call to git_config() to read the default set of configuration
variables at the beginning of the command.

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

xdiff: rename "struct group" to "struct xdlgroup"

Commit e8adf23 (xdl_change_compact(): introduce the concept
of a change group, 2016-08-22) added a "struct group" type
to xdiff/xdiffi.c. But the POSIX system header "grp.h"
already defines "struct group" (it is part of the getgrnam
interface). This happens to work because the new type is
local to xdiffi.c, and the xdiff code includes a relatively
small set of system headers. But it will break compilation
if xdiff ever switches to using git-compat-util.h.  It can
also probably cause confusion with tools that look at the
whole code base, like coccinelle or ctags.

Let's resolve by giving the xdiff variant a scoped name,
which is closer to other xdiff types anyway (e.g.,
xdlfile_t, though note that xdiff is fond if typedefs when
Git usually is not).

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

add David Turner's Two Sigma address

Signed-off-by: David Turner <novalis@novalis.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fifth batch for 2.11

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

Merge branch 'jk/clone-recursive-progress'

"git clone --recurse-submodules" lost the progress eye-candy in
recent update, which has been corrected.

* jk/clone-recursive-progress:
  clone: pass --progress decision to recursive submodules

Merge branch 'jk/doc-cvs-update'

Documentation around tools to import from CVS was fairly outdated.

* jk/doc-cvs-update:
  docs/cvs-migration: mention cvsimport caveats
  docs/cvs-migration: update link to cvsps homepage
  docs/cvsimport: prefer cvs-fast-export to parsecvs

Merge branch 'rt/rebase-i-broken-insn-advise'

When "git rebase -i" is given a broken instruction, it told the
user to fix it with "--edit-todo", but didn't say what the step
after that was (i.e. "--continue").

* rt/rebase-i-broken-insn-advise:
  rebase -i: improve advice on bad instruction lines

Merge branch 'rs/checkout-init-macro'

Code cleanup.

* rs/checkout-init-macro:
  introduce CHECKOUT_INIT

Merge branch 'ls/travis-homebrew-path-fix'

The procedure to build Git on Mac OS X for Travis CI hardcoded the
internal directory structure we assumed HomeBrew uses, which was a
no-no.  The procedure has been updated to ask HomeBrew things we
need to know to fix this.

* ls/travis-homebrew-path-fix:
  travis-ci: ask homebrew for its path instead of hardcoding it

Merge branch 'tg/add-chmod+x-fix'

"git add --chmod=+x <pathspec>" added recently only toggled the
executable bit for paths that are either new or modified. This has
been corrected to flip the executable bit for all paths that match
the given pathspec.

* tg/add-chmod+x-fix:
  t3700-add: do not check working tree file mode without POSIXPERM
  t3700-add: create subdirectory gently
  add: modify already added files when --chmod is given
  read-cache: introduce chmod_index_entry
  update-index: add test for chmod flags

Merge branch 'js/regexec-buf'

Some codepaths in "git diff" used regexec(3) on a buffer that was
mmap(2)ed, which may not have a terminating NUL, leading to a read
beyond the end of the mapped region.  This was fixed by introducing
a regexec_buf() helper that takes a <ptr,len> pair with REG_STARTEND
extension.

* js/regexec-buf:
  regex: use regexec_buf()
  regex: add regexec_buf() that can work on a non NUL-terminated string
  regex: -G<pattern> feeds a non NUL-terminated string to regexec() and fails

Merge branch 'nd/checkout-disambiguation'

"git checkout <word>" does not follow the usual disambiguation
rules when the <word> can be both a rev and a path, to allow
checking out a branch 'foo' in a project that happens to have a
file 'foo' in the working tree without having to disambiguate.
This was poorly documented and the check was incorrect when the
command was run from a subdirectory.

* nd/checkout-disambiguation:
  checkout: fix ambiguity check in subdir
  checkout.txt: document a common case that ignores ambiguation rules
  checkout: add some spaces between code and comment

Merge branch 'va/i18n-more'

Even more i18n.

* va/i18n-more:
  i18n: stash: mark messages for translation
  i18n: notes-merge: mark die messages for translation
  i18n: ident: mark hint for translation
  i18n: i18n: diff: mark die messages for translation
  i18n: connect: mark die messages for translation
  i18n: commit: mark message for translation

Merge branch 'jt/format-patch-rfc'

In some projects, it is common to use "[RFC PATCH]" as the subject
prefix for a patch meant for discussion rather than application.  A
new option "--rfc" was a short-hand for "--subject-prefix=RFC PATCH"
to help the participants of such projects.

* jt/format-patch-rfc:
  format-patch: add "--rfc" for the common case of [RFC PATCH]

Merge branch 'ep/doc-check-ref-format-example'

A shell script example in check-ref-format documentation has been
fixed.

* ep/doc-check-ref-format-example:
  git-check-ref-format.txt: fixup documentation

Merge branch 'mh/diff-indent-heuristic'

Output from "git diff" can be made easier to read by selecting
which lines are common and which lines are added/deleted
intelligently when the lines before and after the changed section
are the same.  A command line option is added to help with the
experiment to find a good heuristics.

* mh/diff-indent-heuristic:
  blame: honor the diff heuristic options and config
  parse-options: add parse_opt_unknown_cb()
  diff: improve positioning of add/delete blocks in diffs
  xdl_change_compact(): introduce the concept of a change group
  recs_match(): take two xrecord_t pointers as arguments
  is_blank_line(): take a single xrecord_t as argument
  xdl_change_compact(): only use heuristic if group can't be matched
  xdl_change_compact(): fix compaction heuristic to adjust ixo

Merge branch 'rs/c-auto-resets-attributes'

The pretty-format specifier "%C(auto)" used by the "log" family of
commands to enable coloring of the output is taught to also issue a
color-reset sequence to the output.

* rs/c-auto-resets-attributes:
  pretty: let %C(auto) reset all attributes

Merge branch 'mm/config-color-ui-default-to-auto'

Documentation for individual configuration variables to control use
of color (like `color.grep`) said that their default value is
'false', instead of saying their default is taken from `color.ui`.
When we updated the default value for color.ui from 'false' to
'auto' quite a while ago, all of them broke.  This has been
corrected.

* mm/config-color-ui-default-to-auto:
  Documentation/config: default for color.* is color.ui

Merge branch 'rs/cocci'

Code cleanup.

* rs/cocci:
  use strbuf_addstr() for adding constant strings to a strbuf, part 2
  add coccicheck make target
  contrib/coccinelle: fix semantic patch for oid_to_hex_r()

unpack_sha1_header(): detect malformed object header

When opening a loose object file, we often do this sequence:

 - prepare a short buffer for the object header (on stack)

 - call unpack_sha1_header() and have early part of the object data
   inflated, enough to fill the buffer

 - parse that data in the short buffer, assuming that the first part
   of the object is <typename> SP <length> NUL

Because the parsing function parse_sha1_header_extended() is not
given the number of bytes inflated into the header buffer, it you
craft a file whose early part inflates a garbage sequence without SP
or NUL, and replace a loose object with it, it will end up reading
past the end of the inflated data.

To correct this, do the following four things:

 - rename unpack_sha1_header() to unpack_sha1_short_header() and
   have unpack_sha1_header_to_strbuf() keep calling that as its
   helper function.  This will detect and report zlib errors, but is
   not aware of the format of a loose object (as before).

 - introduce unpack_sha1_header() that calls the same helper
   function, and when zlib reports it inflated OK into the buffer,
   check if the inflated data has NUL.  This would ensure that
   parsing function will terminate within the buffer that holds the
   inflated header.

 - update unpack_sha1_header_to_strbuf() to check if the resulting
   buffer has NUL for the same effect.

 - update parse_sha1_header_extended() to make sure that its loop to
   find the SP that terminates the <typename> stops at NUL.

Essentially, this makes unpack_*() functions that are asked to
unpack a loose object header to be a bit more strict and detect an
input that cannot possibly be a valid object header, even before the
parsing function kicks in.

Reported-by: Gustavo Grieco <gustavo.grieco@imag.fr>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

streaming: make sure to notice corrupt object

The streaming read interface from a loose object called
parse_sha1_header() but discarded its return value, without noticing
a potential error.

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

Merge branch 'va/i18n' of ../git-gui into va/git-gui-i18n

* 'va/i18n' of ../git-gui:
  git-gui: l10n: add Portuguese translation
  git-gui i18n: mark strings for translation

git-gui: l10n: add Portuguese translation

Add Portuguese glossary.

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui i18n: mark strings for translation

Mark strings for translation in lib/index.tcl that were seemingly
left behind by 700e560 ("git-gui: Mark forgotten strings for
translation.", 2008-09-04) which marks string in do_revert_selection
procedure.
These strings are passed to unstage_help and add_helper procedures.

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'rs/use-modern-git-merge-syntax' of git-gui into rs/git-gui-use-modern-git-merge-syntax

* 'rs/use-modern-git-merge-syntax' of git-gui:
  git-gui: stop using deprecated merge syntax

git-gui: stop using deprecated merge syntax

Starting with v2.5.0 git merge can handle FETCH_HEAD internally and
warns when it's called like 'git merge <message> HEAD <commit>' because
that syntax is deprecated.  Use this feature in git-gui and get rid of
that warning.

Signed-off-by: Rene Scharfe <l.s.r@web.de>
Tested-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

use COPY_ARRAY

Add a semantic patch for converting certain calls of memcpy(3) to
COPY_ARRAY() and apply that transformation to the code base.  The result
is
 shorter and safer code.  For now only consider calls where source and
destination have the same type, or in other words: easy cases.

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

add COPY_ARRAY

Add COPY_ARRAY, a safe and convenient helper for copying arrays,
complementing ALLOC_ARRAY and REALLOC_ARRAY.  Users just specify source,
destination and the number of elements; the size of an element is
inferred automatically.

It checks if the multiplication of size and element count overflows.
The inferred size is passed first to st_mult, which allows the division
there to be done at compilation time.

As a basic type safety check it makes sure the sizes of source and
destination elements are the same.  That's evaluated at compilation time
as well.

COPY_ARRAY is safe to use with NULL as source pointer iff 0 elements are
to be copied.  That convention is used in some cases for initializing
arrays.  Raw memcpy(3) does not support it -- compilers are allowed to
assume that only valid pointers are passed to it and can optimize away
NULL checks after such a call.

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

gitweb: use highlight's shebang detection

The "highlight" binary can, in some cases, determine the language type
by the means of file contents, for example the shebang in the first line
for some scripting languages.  Make use of this autodetection for files
which syntax is not known by gitweb.  In that case, pass the blob
contents to "highlight --force"; the parameter is needed to make it
always generate HTML output (which includes HTML-escaping).

Although we now run highlight on files which do not end up highlighted,
performance is virtually unaffected because when we call highlight, it
is used for escaping HTML.  In the case that highlight is used, gitweb
calls sanitize() instead of esc_html(), and the latter is significantly
slower (it does more, being roughly a superset of sanitize()).  Simple
benchmark comparing performance of 'blob' view of files without syntax
highlighting in gitweb before and after this change indicates ±1%
difference in request time for all file types.  Benchmark was performed
on local instance on Debian, using Apache/2.4.23 web server and CGI.

Document the feature and improve syntax highlight documentation, add
test to ensure gitweb doesn't crash when language detection is used.

Signed-off-by: Ian Kelling <ian@iankelling.org>
Acked-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitweb: remove unused guess_file_syntax() parameter

Signed-off-by: Ian Kelling <ian@iankelling.org>
Acked-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

init: kill git_link variable

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

init: do not set unnecessary core.worktree

The function needs_work_tree_config() that is called from
create_default_files() is supposed to be fed the path to ".git" that
looks as if it is at the top of the working tree, and decide if that
location matches the actual worktree being used.  This comparison allows
"git init" to decide if core.worktree needs to be recorded in the
working tree.

In the current code, however, we feed the return value from
get_git_dir(), which can be totally different from what the function
expects when "gitdir" file is involved.  Instead of giving the path to
the ".git" at the top of the working tree, we end up feeding the actual
path that the file points at.

This original location of ".git" however is only known to init_db().
Make init_db() save it and have it passed to create_default_files() as a
new parameter, which passes the correct location down to
needs_work_tree_config() to fix this.

Noticed-by: Max Nordlund <max.nordlund@sqore.com>
Helped-by: Michael J Gruber <git@drmicha.warpmail.net>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

init: kill set_git_dir_init()

This is a pure code move, necessary to kill the global variable git_link
later (and also helps a bit in the next patch).

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

init: call set_git_dir_init() from within init_db()

The next commit requires that set_git_dir_init() must be called before
init_db(). Let's make sure nobody can do otherwise.

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

init: correct re-initialization from a linked worktree

When 'git init' is called from a linked worktree, we treat '.git'
dir (which is $GIT_COMMON_DIR/worktrees/something) as the main
'.git' (i.e. $GIT_COMMON_DIR) and populate the whole repository skeleton
in there. It does not harm anything (*) but it is still wrong.

Since 'git init' calls set_git_dir() at preparation time, which
indirectly calls get_common_dir() and correctly detects multiple
worktree setup, all git_path_buf() calls in create_default_files() will
return correct paths in both single and multiple worktree setups. The
only thing left is copy_templates(), which targets $GIT_DIR, not
$GIT_COMMON_DIR.

Fix that with get_git_common_dir(). This function will return $GIT_DIR
in single-worktree setup, so we don't have to make a special case for
multiple-worktree here.

(*) It does in fact, thanks to another bug. More on that later.

Noticed-by: Max Nordlund <max.nordlund@sqore.com>
Helped-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch-pack: do not reset in_vain on non-novel acks

The MAX_IN_VAIN mechanism was introduced in commit f061e5f ("fetch-pack:
give up after getting too many "ack continue"", 2006-05-24) to stop ref
negotiation if a number of consecutive "have"s have been sent with no
corresponding new acks. This is to stop the client from digging too deep
in an irrelevant side branch in vain without ever finding a common
ancestor. A use case (as described in that commit) is the scenario in
which the local repository has more roots than the remote repository.

However, during a negotiation in which stateless RPCs are used,
MAX_IN_VAIN will (almost) never trigger (in the more-roots scenario
above and others) because in each new request, the client has to inform
the server of objects it already has and knows the server has (to remind
the server of the state), which the server then acks.

Make fetch-pack only consider, as new acks for the purpose of
MAX_IN_VAIN, acks for objects for which the client has never received an
ack before in this session.

Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ident: handle NULL ai_canonname

We call getaddrinfo() to try to convert a short hostname
into a fully-qualified one (to use it as an email domain).
If there isn't a canonical name, getaddrinfo() will
generally return either a NULL addrinfo list, or one in
which ai->ai_canonname is a copy of the original name.

However, if the result of gethostname() looks like an IP
address, then getaddrinfo() behaves differently on some
systems. On OS X, it will return a "struct addrinfo" with a
NULL ai_canonname, and we segfault feeding it to strchr().

This is hard to test reliably because it involves not only a
system where we we have to fallback to gethostname() to come
up with an ident, but also where the hostname is a number
with no dots. But I was able to replicate the bug by faking
a hostname, like:

    diff --git a/ident.c b/ident.c
    index e20a772..b790d28 100644
    --- a/ident.c
    +++ b/ident.c
    @@ -128,6 +128,7 @@ static void add_domainname(struct strbuf *out, int *is_bogus)
                     *is_bogus = 1;
                     return;
             }
    +        xsnprintf(buf, sizeof(buf), "1");
             if (strchr(buf, '.'))
                     strbuf_addstr(out, buf);
             else if (canonical_name(buf, out) < 0) {

and running "git var GIT_AUTHOR_IDENT" on an OS X system.

Before this patch it segfaults, and after we correctly
complain of the bogus "user@1.(none)" address (though this
bogus address would be suitable for non-object uses like
writing reflogs).

Reported-by: Jonas Thiel <jonas.lierschied@gmx.de>
Diagnosed-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

introduce CHECKOUT_INIT

Add a static initializer for struct checkout and use it throughout the
code base.  It's shorter, avoids a memset(3) call and makes sure the
base_dir member is initialized to a valid (empty) string.

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

docs/cvs-migration: mention cvsimport caveats

Back when this guide was written, cvsimport was the only
game in town. These days it is probably not the best option.
Rather than go into details, let's point people to the note
at the top of cvsimport which gives other options.

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

docs/cvs-migration: update link to cvsps homepage

The old page gives a 404 now. Searching for "cvsps" via
Google returns a GitHub project page as the top hit.

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

docs/cvsimport: prefer cvs-fast-export to parsecvs

parsecvs maintenance was taken over by ESR, and the name
changed to cvs-fast-export as it learned to support that
output format. Let's point to cvs-fast-export, as it should
have additional bug-fixes and be more convenient to use.

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

clone: pass --progress decision to recursive submodules

When cloning with "--recursive", we'd generally expect
submodules to show progress reports if the main clone did,
too.

In older versions of git, this mostly worked out of the
box. Since we show progress by default when stderr is a tty,
and since the child clones inherit the parent stderr, then
both processes would come to the same decision by default.
If the parent clone was asked for "--quiet", we passed down
"--quiet" to the child. However, if stderr was not a tty and
the user specified "--progress", we did not propagate this
to the child.

That's a minor bug, but things got much worse when we
switched recently to submodule--helper's update_clone
command. With that change, the stderr of the child clones
are always connected to a pipe, and we never output
progress at all.

This patch teaches git-submodule and git-submodule--helper
how to pass down an explicit "--progress" flag when cloning.
The clone command then decides to propagate that flag based
on the cloning decision made earlier (which takes into
account isatty(2) of the parent process, existing --progress
or --quiet flags, etc). Since the child processes always run
without a tty on stderr, we don't have to worry about
passing an explicit "--no-progress"; it's the default for
them.

This fixes the recent loss of progress during recursive
clones. And as a bonus, it makes:

  git clone --recursive --progress ... 2>&1 | cat

work by triggering progress explicitly in the children.

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

verify_packfile: check pack validity before accessing data

The verify_packfile() does not explicitly open the packfile;
instead, it starts with a sha1 checksum over the whole pack,
and relies on use_pack() to open the packfile as a side
effect.

If the pack cannot be opened for whatever reason (either
because its header information is corrupted, or perhaps
because a simultaneous repack deleted it), then use_pack()
will die(), as it has no way to return an error. This is not
ideal, as verify_packfile() otherwise tries to gently return
an error (this lets programs like git-fsck go on to check
other packs).

Instead, let's check is_pack_valid() up front, and return an
error if it fails. This will open the pack as a side effect,
and then use_pack() will later rely on our cached
descriptor, and avoid calling die().

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

travis-ci: ask homebrew for its path instead of hardcoding it

The TravisCI macOS build is broken because homebrew (a macOS dependency
manager) changed its internal directory structure [1]. This is a problem
because we modify the Perforce dependencies in the homebrew repository
before installing them.

Fix it by asking homebrew for its path instead of hardcoding it.

[1] https://github.com/Homebrew/brew/commit/0a09ae30f8b6117ad699b4a0439010738989c547

Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fourth batch for 2.11

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

Merge branch 'jk/reduce-gc-aggressive-depth'

"git gc --aggressive" used to limit the delta-chain length to 250,
which is way too deep for gaining additional space savings and is
detrimental for runtime performance.  The limit has been reduced to
50.

* jk/reduce-gc-aggressive-depth:
  gc: default aggressive depth to 50

Merge branch 'jk/rebase-i-drop-ident-check'

Even when "git pull --rebase=preserve" (and the underlying "git
rebase --preserve") can complete without creating any new commit
(i.e. fast-forwards), it still insisted on having a usable ident
information (read: user.email is set correctly), which was less
than nice.  As the underlying commands used inside "git rebase"
would fail with a more meaningful error message and advice text
when the bogus ident matters, this extra check was removed.

* jk/rebase-i-drop-ident-check:
  rebase-interactive: drop early check for valid ident

Merge branch 'va/i18n'

More i18n.

* va/i18n:
  i18n: update-index: mark warnings for translation
  i18n: show-branch: mark plural strings for translation
  i18n: show-branch: mark error messages for translation
  i18n: receive-pack: mark messages for translation
  notes: spell first word of error messages in lowercase
  i18n: notes: mark error messages for translation
  i18n: merge-recursive: mark verbose message for translation
  i18n: merge-recursive: mark error messages for translation
  i18n: config: mark error message for translation
  i18n: branch: mark option description for translation
  i18n: blame: mark error messages for translation

Merge branch 'jt/format-patch-base-info-above-sig'

"git format-patch --base=..." feature that was recently added
showed the base commit information after "-- " e-mail signature
line, which turned out to be inconvenient.  The base information
has been moved above the signature line.

* jt/format-patch-base-info-above-sig:
  format-patch: show base info before email signature

Merge branch 'ks/perf-build-with-autoconf'

Performance tests done via "t/perf" did not use the same set of
build configuration if the user relied on autoconf generated
configuration.

* ks/perf-build-with-autoconf:
  t/perf/run: copy config.mak.autogen & friends to build area

Merge branch 'mr/vcs-svn-printf-ulong'

Code cleanup.

* mr/vcs-svn-printf-ulong:
  vcs-svn/fast_export: fix timestamp fmt specifiers

Merge branch 'rs/xdiff-merge-overlapping-hunks-for-W-context'

"git diff -W" output needs to extend the context backward to
include the header line of the current function and also forward to
include the body of the entire current function up to the header
line of the next one.  This process may have to merge to adjacent
hunks, but the code forgot to do so in some cases.

* rs/xdiff-merge-overlapping-hunks-for-W-context:
  xdiff: fix merging of hunks with -W context and -u context

Merge branch 'rs/unpack-trees-reduce-file-scope-global'

Code cleanup.

* rs/unpack-trees-reduce-file-scope-global:
  unpack-trees: pass checkout state explicitly to check_updates()

Merge branch 'rs/strbuf-remove-fix'

Code cleanup.

* rs/strbuf-remove-fix:
  strbuf: use valid pointer in strbuf_remove()

Merge branch 'rs/pack-sort-with-llist-mergesort'

Code cleanup.

* rs/pack-sort-with-llist-mergesort:
  sha1_file: use llist_mergesort() for sorting packs