gitweb.git
Merge branch 'sb/submodule-clone-rr'Junio C Hamano Fri, 9 Sep 2016 04:49:50 +0000 (21:49 -0700)

Merge branch 'sb/submodule-clone-rr'

"git clone --resurse-submodules --reference $path $URL" is a way to
reduce network transfer cost by borrowing objects in an existing
$path repository when cloning the superproject from $URL; it
learned to also peek into $path for presense of corresponding
repositories of submodules and borrow objects from there when able.

* sb/submodule-clone-rr:
clone: recursive and reference option triggers submodule alternates
clone: implement optional references
clone: clarify option_reference as required
clone: factor out checking for an alternate path
submodule--helper update-clone: allow multiple references
submodule--helper module-clone: allow multiple references
t7408: merge short tests, factor out testing method
t7408: modernize style

Merge branch 'jh/status-v2-porcelain'Junio C Hamano Fri, 9 Sep 2016 04:49:50 +0000 (21:49 -0700)

Merge branch 'jh/status-v2-porcelain'

Enhance "git status --porcelain" output by collecting more data on
the state of the index and the working tree files, which may
further be used to teach git-prompt (in contrib/) to make fewer
calls to git.

* jh/status-v2-porcelain:
status: unit tests for --porcelain=v2
test-lib-functions.sh: add lf_to_nul helper
git-status.txt: describe --porcelain=v2 format
status: print branch info with --porcelain=v2 --branch
status: print per-file porcelain v2 status data
status: collect per-file data for --porcelain=v2
status: support --porcelain[=<version>]
status: cleanup API to wt_status_print
status: rename long-format print routines

Merge branch 'po/range-doc'Junio C Hamano Fri, 9 Sep 2016 04:49:49 +0000 (21:49 -0700)

Merge branch 'po/range-doc'

Clarify various ways to specify the "revision ranges" in the
documentation.

* po/range-doc:
doc: revisions: sort examples and fix alignment of the unchanged
doc: revisions: show revision expansion in examples
doc: revisions - clarify reachability examples
doc: revisions - define `reachable`
doc: gitrevisions - clarify 'latter case' is revision walk
doc: gitrevisions - use 'reachable' in page description
doc: revisions: single vs multi-parent notation comparison
doc: revisions: extra clarification of <rev>^! notation effects
doc: revisions: give headings for the two and three dot notations
doc: show the actual left, right, and boundary marks
doc: revisions - name the left and right sides
doc: use 'symmetric difference' consistently

Merge branch 'rt/help-unknown'Junio C Hamano Fri, 9 Sep 2016 04:49:48 +0000 (21:49 -0700)

Merge branch 'rt/help-unknown'

"git nosuchcommand --help" said "No manual entry for gitnosuchcommand",
which was not intuitive, given that "git nosuchcommand" said "git:
'nosuchcommand' is not a git command".

* rt/help-unknown:
help: make option --help open man pages only for Git commands
help: introduce option --exclude-guides

Merge branch 'cc/receive-pack-limit'Junio C Hamano Fri, 9 Sep 2016 04:49:47 +0000 (21:49 -0700)

Merge branch 'cc/receive-pack-limit'

An incoming "git push" that attempts to push too many bytes can now
be rejected by setting a new configuration variable at the receiving
end.

* cc/receive-pack-limit:
receive-pack: allow a maximum input size to be specified
unpack-objects: add --max-input-size=<size> option
index-pack: add --max-input-size=<size> option

Merge branch 'jk/format-patch-number-singleton-patch... Junio C Hamano Fri, 9 Sep 2016 04:49:47 +0000 (21:49 -0700)

Merge branch 'jk/format-patch-number-singleton-patch-with-cover'

"git format-patch --cover-letter HEAD^" to format a single patch
with a separate cover letter now numbers the output as [PATCH 0/1]
and [PATCH 1/1] by default.

* jk/format-patch-number-singleton-patch-with-cover:
format-patch: show 0/1 and 1/1 for singleton patch with cover letter

Merge branch 'jk/delta-base-cache'Junio C Hamano Fri, 9 Sep 2016 04:49:46 +0000 (21:49 -0700)

Merge branch 'jk/delta-base-cache'

The delta-base-cache mechanism has been a key to the performance in
a repository with a tightly packed packfile, but it did not scale
well even with a larger value of core.deltaBaseCacheLimit.

* jk/delta-base-cache:
t/perf: add basic perf tests for delta base cache
delta_base_cache: use hashmap.h
delta_base_cache: drop special treatment of blobs
delta_base_cache: use list.h for LRU
release_delta_base_cache: reuse existing detach function
clear_delta_base_cache_entry: use a more descriptive name
cache_or_unpack_entry: drop keep_cache parameter

Git 2.10 v2.10.0Junio C Hamano Fri, 2 Sep 2016 16:05:47 +0000 (09:05 -0700)

Git 2.10

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

Merge tag 'l10n-2.10.0-rnd2.2' of git://github.com... Junio C Hamano Fri, 2 Sep 2016 15:48:14 +0000 (08:48 -0700)

Merge tag 'l10n-2.10.0-rnd2.2' of git://github.com/git-l10n/git-po

l10n-2.10.0-rnd2.2

* tag 'l10n-2.10.0-rnd2.2' of git://github.com/git-l10n/git-po:
l10n: Updated Vietnamese translation for v2.10.0-rc2 (2757t)

Merge branch 'master' of https://github.com/vnwildman/gitJiang Xin Fri, 2 Sep 2016 13:29:48 +0000 (21:29 +0800)

Merge branch 'master' of https://github.com/vnwildman/git

* 'master' of https://github.com/vnwildman/git:
l10n: Updated Vietnamese translation for v2.10.0-rc2 (2757t)

A few more fixes before the final 2.10Junio C Hamano Wed, 31 Aug 2016 17:21:05 +0000 (10:21 -0700)

A few more fixes before the final 2.10

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

Merge tag 'l10n-2.10.0-rnd2' of git://github.com/git... Junio C Hamano Wed, 31 Aug 2016 17:04:14 +0000 (10:04 -0700)

Merge tag 'l10n-2.10.0-rnd2' of git://github.com/git-l10n/git-po

l10n-2.10.0-rnd2

* tag 'l10n-2.10.0-rnd2' of git://github.com/git-l10n/git-po:
l10n: zh_CN: for git v2.10.0 l10n round 2
l10n: ca.po: update translation
l10n: fr.po v2.10.0-rc2
l10n: sv.po: Update Swedish translation (2757t0f0u)
l10n: git.pot: v2.10.0 round 2 (12 new, 44 removed)
l10n: Updated Vietnamese translation for v2.10.0 (2789t)
l10n: pt_PT: update Portuguese translation
l10n: pt_PT: merge git.pot
l10n: ko.po: Update Korean translation
l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed)

Merge branch 'ls/packet-line-protocol-doc-fix'Junio C Hamano Wed, 31 Aug 2016 17:03:51 +0000 (10:03 -0700)

Merge branch 'ls/packet-line-protocol-doc-fix'

Correct an age-old calco (is that a typo-like word for calc)
in the documentation.

* ls/packet-line-protocol-doc-fix:
pack-protocol: fix maximum pkt-line size

Merge branch 'mh/blame-worktree'Junio C Hamano Wed, 31 Aug 2016 17:03:50 +0000 (10:03 -0700)

Merge branch 'mh/blame-worktree'

* mh/blame-worktree:
blame: fix segfault on untracked files

Merge branch 'kw/patch-ids-optim'Junio C Hamano Wed, 31 Aug 2016 17:03:49 +0000 (10:03 -0700)

Merge branch 'kw/patch-ids-optim'

* kw/patch-ids-optim:
p3400: make test script executable

help: make option --help open man pages only for Git... Ralf Thielow Fri, 26 Aug 2016 17:58:36 +0000 (19:58 +0200)

help: make option --help open man pages only for Git commands

If option --help is passed to a Git command, we try to open
the man page of that command. However, we do it for both commands
and concepts. Make sure it is an actual command.

This makes "git <concept> --help" not working anymore, while
"git help <concept>" still works.

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

help: introduce option --exclude-guidesRalf Thielow Fri, 26 Aug 2016 17:58:35 +0000 (19:58 +0200)

help: introduce option --exclude-guides

Introduce option --exclude-guides to the help command. With this option
being passed, "git help" will open man pages only for actual commands.

Since we know it is a command, we can use function help_unknown_command
to give the user advice on typos.

Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pack-protocol: fix maximum pkt-line sizeLars Schneider Mon, 29 Aug 2016 17:55:09 +0000 (19:55 +0200)

pack-protocol: fix maximum pkt-line size

According to LARGE_PACKET_MAX in pkt-line.h the maximal length of a
pkt-line packet is 65520 bytes. The pkt-line header takes 4 bytes and
therefore the pkt-line data component must not exceed 65516 bytes.

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

l10n: zh_CN: for git v2.10.0 l10n round 2Jiang Xin Sun, 28 Aug 2016 02:18:12 +0000 (10:18 +0800)

l10n: zh_CN: for git v2.10.0 l10n round 2

Update 215 translations (2757t0f0u) for git v2.10.0-rc2.

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

p3400: make test script executableRené Scharfe Sun, 28 Aug 2016 12:39:27 +0000 (14:39 +0200)

p3400: make test script executable

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

blame: fix segfault on untracked filesThomas Gummerer Sat, 27 Aug 2016 20:01:50 +0000 (21:01 +0100)

blame: fix segfault on untracked files

Since 3b75ee9 ("blame: allow to blame paths freshly added to the index",
2016-07-16) git blame also looks at the index to determine if there is a
file that was freshly added to the index.

cache_name_pos returns -pos - 1 in case there is no match is found, or
if the name matches, but the entry has a stage other than 0. As git
blame should work for unmerged files, it uses strcmp to determine
whether the name of the returned position matches, in which case the
file exists, but is merely unmerged, or if the file actually doesn't
exist in the index.

If the repository is empty, or if the file would lexicographically be
sorted as the last file in the repository, -cache_name_pos - 1 is
outside of the length of the active_cache array, causing git blame to
segfault. Guard against that, and die() normally to restore the old
behaviour.

Reported-by: Simon Ruderich <simon@ruderich.org>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: ca.po: update translationAlex Henrie Sun, 28 Aug 2016 16:32:56 +0000 (10:32 -0600)

l10n: ca.po: update translation

Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>

l10n: fr.po v2.10.0-rc2Jean-Noel Avila Sat, 20 Aug 2016 14:20:17 +0000 (16:20 +0200)

l10n: fr.po v2.10.0-rc2

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>

l10n: Updated Vietnamese translation for v2.10.0-rc2... Tran Ngoc Quan Sun, 28 Aug 2016 00:23:30 +0000 (07:23 +0700)

l10n: Updated Vietnamese translation for v2.10.0-rc2 (2757t)

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>

l10n: sv.po: Update Swedish translation (2757t0f0u)Peter Krefting Fri, 26 Aug 2016 13:27:24 +0000 (14:27 +0100)

l10n: sv.po: Update Swedish translation (2757t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

Merge branch 'master' of https://github.com/vnwildman/gitJiang Xin Sat, 27 Aug 2016 15:36:16 +0000 (23:36 +0800)

Merge branch 'master' of https://github.com/vnwildman/git

* 'master' of https://github.com/vnwildman/git:
l10n: Updated Vietnamese translation for v2.10.0 (2789t)

l10n: git.pot: v2.10.0 round 2 (12 new, 44 removed)Jiang Xin Sat, 27 Aug 2016 15:23:26 +0000 (23:23 +0800)

l10n: git.pot: v2.10.0 round 2 (12 new, 44 removed)

Generate po/git.pot from v2.10.0-rc2 for git v2.10.0 l10n round 2.

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

Merge branch 'master' of git://github.com/git-l10n... Jiang Xin Sat, 27 Aug 2016 15:14:27 +0000 (23:14 +0800)

Merge branch 'master' of git://github.com/git-l10n/git-po

* 'master' of git://github.com/git-l10n/git-po:
l10n: pt_PT: update Portuguese translation
l10n: pt_PT: merge git.pot
l10n: ko.po: Update Korean translation
l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed)

l10n: Updated Vietnamese translation for v2.10.0 (2789t)Tran Ngoc Quan Sat, 27 Aug 2016 02:15:28 +0000 (09:15 +0700)

l10n: Updated Vietnamese translation for v2.10.0 (2789t)

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>

Git 2.10-rc2 v2.10.0-rc2Junio C Hamano Fri, 26 Aug 2016 20:59:20 +0000 (13:59 -0700)

Git 2.10-rc2

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

gitattributes: Document the unified "auto" handlingTorsten Bögershausen Fri, 26 Aug 2016 20:18:48 +0000 (22:18 +0200)

gitattributes: Document the unified "auto" handling

Update the documentation about text=auto:
text=auto now follows the core.autocrlf handling when files are not
normalized in the repository.

For a cross platform project recommend the usage of attributes for
line-ending conversions.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'js/no-html-bypass-on-windows' into rt... Junio C Hamano Fri, 26 Aug 2016 18:29:07 +0000 (11:29 -0700)

Merge branch 'js/no-html-bypass-on-windows' into rt/help-unknown

* js/no-html-bypass-on-windows:
Revert "display HTML in default browser using Windows' shell API"

Prepare for 2.10.0-rc2Junio C Hamano Thu, 25 Aug 2016 20:56:51 +0000 (13:56 -0700)

Prepare for 2.10.0-rc2

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

Merge branch 'ja/i18n'Junio C Hamano Thu, 25 Aug 2016 20:55:07 +0000 (13:55 -0700)

Merge branch 'ja/i18n'

The recent i18n patch we added during this cycle did a bit too much
refactoring of the messages to avoid word-legos; the repetition has
been reduced to help translators.

* ja/i18n:
i18n: simplify numeric error reporting
i18n: fix git rebase interactive commit messages
i18n: fix typos for translation

Merge branch 'bw/mingw-avoid-inheriting-fd-to-lockfile'Junio C Hamano Thu, 25 Aug 2016 20:55:07 +0000 (13:55 -0700)

Merge branch 'bw/mingw-avoid-inheriting-fd-to-lockfile'

The tempfile (hence its user lockfile) API lets the caller to open
a file descriptor to a temporary file, write into it and then
finalize it by first closing the filehandle and then either
removing or renaming the temporary file. When the process spawns a
subprocess after obtaining the file descriptor, and if the
subprocess has not exited when the attempt to remove or rename is
made, the last step fails on Windows, because the subprocess has
the file descriptor still open. Open tempfile with O_CLOEXEC flag
to avoid this (on Windows, this is mapped to O_NOINHERIT).

* bw/mingw-avoid-inheriting-fd-to-lockfile:
mingw: ensure temporary file handles are not inherited by child processes
t6026-merge-attr: child processes must not inherit index.lock handles

Merge branch 'dg/document-git-c-in-git-config-doc'Junio C Hamano Thu, 25 Aug 2016 20:55:07 +0000 (13:55 -0700)

Merge branch 'dg/document-git-c-in-git-config-doc'

The "git -c var[=val] cmd" facility to append a configuration
variable definition at the end of the search order was described in
git(1) manual page, but not in git-config(1), which was more likely
place for people to look for when they ask "can I make a one-shot
override, and if so how?"

* dg/document-git-c-in-git-config-doc:
doc: mention `git -c` in git-config(1)

Merge branch 'js/no-html-bypass-on-windows'Junio C Hamano Thu, 25 Aug 2016 20:55:06 +0000 (13:55 -0700)

Merge branch 'js/no-html-bypass-on-windows'

On Windows, help.browser configuration variable used to be ignored,
which has been corrected.

* js/no-html-bypass-on-windows:
Revert "display HTML in default browser using Windows' shell API"

Merge branch 'hv/doc-commit-reference-style'Junio C Hamano Thu, 25 Aug 2016 20:55:05 +0000 (13:55 -0700)

Merge branch 'hv/doc-commit-reference-style'

A small doc update.

* hv/doc-commit-reference-style:
SubmittingPatches: document how to reference previous commits

git ls-files: text=auto eol=lf is supported in Git... Torsten Bögershausen Thu, 25 Aug 2016 15:52:57 +0000 (17:52 +0200)

git ls-files: text=auto eol=lf is supported in Git 2.10

The man page for `git ls-files --eol` mentions the combination
of text attributes "text=auto eol=lf" or "text=auto eol=crlf" as not
supported yet, but may be in the future.

Now they are supported.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: pt_PT: update Portuguese translationVasco Almeida Mon, 22 Aug 2016 16:29:35 +0000 (16:29 +0000)

l10n: pt_PT: update Portuguese translation

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>

l10n: pt_PT: merge git.potVasco Almeida Tue, 16 Aug 2016 12:06:44 +0000 (12:06 +0000)

l10n: pt_PT: merge git.pot

Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>

receive-pack: allow a maximum input size to be specifiedJeff King Wed, 24 Aug 2016 18:41:57 +0000 (20:41 +0200)

receive-pack: allow a maximum input size to be specified

Receive-pack feeds its input to either index-pack or
unpack-objects, which will happily accept as many bytes as
a sender is willing to provide. Let's allow an arbitrary
cutoff point where we will stop writing bytes to disk.

Cleaning up what has already been written to disk is a
related problem that is not addressed by this patch.

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

unpack-objects: add --max-input-size=<size> optionChristian Couder Wed, 24 Aug 2016 18:41:56 +0000 (20:41 +0200)

unpack-objects: add --max-input-size=<size> option

When receiving a pack-file, it can be useful to abort the
`git unpack-objects`, if the pack-file is too big.

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

index-pack: add --max-input-size=<size> optionJeff King Wed, 24 Aug 2016 18:41:55 +0000 (20:41 +0200)

index-pack: add --max-input-size=<size> option

When receiving a pack-file, it can be useful to abort the
`git index-pack`, if the pack-file is too big.

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

i18n: simplify numeric error reportingJean-Noel Avila Sun, 21 Aug 2016 14:50:39 +0000 (16:50 +0200)

i18n: simplify numeric error reporting

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: fix git rebase interactive commit messagesJean-Noel Avila Sun, 21 Aug 2016 14:50:38 +0000 (16:50 +0200)

i18n: fix git rebase interactive commit messages

For proper i18n, the logic cannot embed english specific processing.

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: fix typos for translationJean-Noel Avila Sun, 21 Aug 2016 14:50:37 +0000 (16:50 +0200)

i18n: fix typos for translation

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

format-patch: show 0/1 and 1/1 for singleton patch... Jacob Keller Tue, 23 Aug 2016 22:45:50 +0000 (15:45 -0700)

format-patch: show 0/1 and 1/1 for singleton patch with cover letter

Change the default behavior of git-format-patch to generate numbered
sequence of 0/1 and 1/1 when generating both a cover-letter and a single
patch. This standardizes the cover letter to have 0/N which helps
distinguish the cover letter from the patch itself. Since the behavior
is easily changed via configuration as well as the use of -n and -N this
should be acceptable default behavior.

Add tests for the new default behavior.

Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/perf: add basic perf tests for delta base cacheJeff King Mon, 22 Aug 2016 22:01:10 +0000 (18:01 -0400)

t/perf: add basic perf tests for delta base cache

This just shows off the improvements done by the last few
patches, and gives us a baseline for noticing regressions in
the future. Here are the results with linux.git as the perf
"large repo":

Test origin HEAD
-------------------------------------------------------------------
0003.1: log --raw 43.41(40.36+2.69) 33.86(30.96+2.41) -22.0%
0003.2: log -S 313.61(309.74+3.78) 298.75(295.58+3.00) -4.7%

(for a large repo, the "log -S" improvements are greater if
you bump the delta base cache limit, but I think it makes
sense to test the "stock" behavior, since that is what most
people will see).

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

delta_base_cache: use hashmap.hJeff King Mon, 22 Aug 2016 22:00:07 +0000 (18:00 -0400)

delta_base_cache: use hashmap.h

The fundamental data structure of the delta base cache is a
hash table mapping pairs of "(packfile, offset)" into
structs containing the actual object data. The hash table
implementation dates back to e5e0161 (Implement a simple
delta_base cache, 2007-03-17), and uses a fixed-size table.
The current size is a hard-coded 256 entries.

Because we need to be able to remove objects from the hash
table, entry lookup does not do any kind of probing to
handle collisions. Colliding items simply replace whatever
is in their slot. As a result, we have fewer usable slots
than even the 256 we allocate. At half full, each new item
has a 50% chance of displacing another one. Or another way
to think about it: every item has a 1/256 chance of being
ejected due to hash collision, without regard to our LRU
strategy.

So it would be interesting to see the effect of increasing
the cache size on the runtime for some common operations. As
with the previous patch, we'll measure "git log --raw" for
tree-only operations, and "git log -Sfoo --raw" for
operations that touch trees and blobs. All times are
wall-clock best-of-3, done against fully packed repos with
--depth=50, and the default core.deltaBaseCacheLimit of
96MB.

Here are timings for various values of MAX_DELTA_CACHE
against git.git (the asterisk marks the minimum time for
each operation):

MAX_DELTA_CACHE log-raw log-S
--------------- --------- ---------
256 0m02.227s 0m12.821s
512 0m02.143s 0m10.602s
1024 0m02.127s 0m08.642s
2048 0m02.148s 0m07.123s
4096 0m02.194s 0m06.448s*
8192 0m02.239s 0m06.504s
16384 0m02.144s* 0m06.502s
32768 0m02.202s 0m06.622s
65536 0m02.230s 0m06.677s

The log-raw case isn't changed much at all here (probably
because our trees just aren't that big in the first place,
or possibly because we have so _few_ trees in git.git that
the 256-entry cache is enough). But once we start putting
blobs in the cache, too, we see a big improvement (almost
50%). The curve levels off around 4096, which means that we
can hold about that many entries before hitting the 96MB
memory limit (or possibly that the workload is small enough
that there is simply no more work to be optimized out by
caching more).

(As a side note, I initially timed my existing git.git pack,
which was a base of --aggressive combined with some pulls on
top. So it had quite a few deeper delta chains. The
256-cache case was more like 15s, and it still dropped to
~6.5s in the same way).

Here are the timings for linux.git:

MAX_DELTA_CACHE log-raw log-S
--------------- --------- ---------
256 0m41.661s 5m12.410s
512 0m39.547s 5m07.920s
1024 0m37.054s 4m54.666s
2048 0m35.871s 4m41.194s*
4096 0m34.646s 4m51.648s
8192 0m33.881s 4m55.342s
16384 0m35.190s 5m00.122s
32768 0m35.060s 4m58.851s
65536 0m33.311s* 4m51.420s

As we grow we see a nice 20% speedup in the tree traversal,
and more modest 10% in the log-S. This is probably an
indication that we are bound less by the number of entries,
and more by the memory limit (more on that below). What is
interesting is that the numbers bounce around a bit;
increasing the number of entries isn't always a strict
improvement.

Partially this is due to noise in the measurement. But it
may also be an indication that our LRU ejection scheme is
not optimal. The smaller cache sizes introduce some
randomness into the ejection (due to collisions), which may
sometimes work in our favor (and sometimes not!).

So what is the optimal setting of MAX_DELTA_CACHE? The
"bouncing" in the linux.git log-S numbers notwithstanding,
it mostly seems like bigger is better. And even if we were
to try to find a "sweet spot", these are just two
repositories, that are not necessarily representative. The
shape of history, the size of trees and blobs, the memory
limit configuration, etc, all will affect the outcome.

Rather than trying to find the "right" number, another
strategy is to just switch to a hash table that can actually
store collisions: namely our hashmap.h implementation.

Here are numbers for that compared to the "best" we saw from
adjusting MAX_DELTA_CACHE:

| log-raw | log-S
| best hashmap | best hashmap
| --------- --------- | --------- ---------
git | 0m02.144s 0m02.144s | 0m06.448s 0m06.688s
linux | 0m33.311s 0m33.092s | 4m41.194s 4m57.172s

We can see the results are similar in most cases, which is
what we'd expect. We're not ejecting due to collisions at
all, so this is purely representing the LRU. So really, we'd
expect this to model most closely the larger values of the
static MAX_DELTA_CACHE limit. And that does seem to be
what's happening, including the "bounce" in the linux log-S
case.

So while the value for that case _isn't_ as good as the
optimal one measured above (which was 2048 entries), given
the bouncing I'm hesitant to suggest that 2048 is any kind
of optimum (not even for linux.git, let alone as a general
rule). The generic hashmap has the appeal that it drops the
number of tweakable numbers by one, which means we can focus
on tuning other elements, like the LRU strategy or the
core.deltaBaseCacheLimit setting.

And indeed, if we bump the cache limit to 1G (which is
probably silly for general use, but maybe something people
with big workstations would want to do), the linux.git log-S
time drops to 3m32s. That's something you really _can't_ do
easily with the static hash table, because the number of
entries needs to grow in proportion to the memory limit (so
2048 is almost certainly not going to be the right value
there).

This patch takes that direction, and drops the static hash
table entirely in favor of using the hashmap.h API.

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

delta_base_cache: drop special treatment of blobsJeff King Mon, 22 Aug 2016 21:59:56 +0000 (17:59 -0400)

delta_base_cache: drop special treatment of blobs

When the delta base cache runs out of allowed memory, it has
to drop entries. It does so by walking an LRU list, dropping
objects until we are under the memory limit. But we actually
walk the list twice: once to drop blobs, and then again to
drop other objects (which are generally trees). This comes
from 18bdec1 (Limit the size of the new delta_base_cache,
2007-03-19).

This performs poorly as the number of entries grows, because
any time dropping blobs does not satisfy the limit, we have
to walk the _entire_ list, trees included, looking for blobs
to drop, before starting to drop any trees.

It's not generally a problem now, as the cache is limited to
only 256 entries. But as we could benefit from increasing
that in a future patch, it's worth looking at how it
performs as the cache size grows. And the answer is "not
well".

The table below shows times for various operations with
different values of MAX_DELTA_CACHE (which is not a run-time
knob; I recompiled with -DMAX_DELTA_CACHE=$n for each).

I chose "git log --raw" ("log-raw" in the table) because it
will access all of the trees, but no blobs at all (so in a
sense it is a worst case for this problem, because we will
always walk over the entire list of trees once before
realizing there are no blobs to drop). This is also
representative of other tree-only operations like "rev-list
--objects" and "git log -- <path>".

I also timed "git log -Sfoo --raw" ("log-S" in the table).
It similarly accesses all of the trees, but also the blobs
for each commit. It's representative of "git log -p", though
it emphasizes the cost of blob access more, as "-S" is
cheaper than computing an actual blob diff.

All timings are best-of-3 wall-clock times (though they all
were CPU bound, so the user CPU times are similar). The
repositories were fully packed with --depth=50, and the
default core.deltaBaseCacheLimit of 96M was in effect. The
current value of MAX_DELTA_CACHE is 256, so I started there
and worked up by factors of 2.

First, here are values for git.git (the asterisk signals the
fastest run for each operation):

MAX_DELTA_CACHE log-raw log-S
--------------- --------- ---------
256 0m02.212s 0m12.634s
512 0m02.136s* 0m10.614s
1024 0m02.156s 0m08.614s
2048 0m02.208s 0m07.062s
4096 0m02.190s 0m06.484s*
8192 0m02.176s 0m07.635s
16384 0m02.913s 0m19.845s
32768 0m03.617s 1m05.507s
65536 0m04.031s 1m18.488s

You can see that for the tree-only log-raw case, we don't
actually benefit that much as the cache grows (all the
differences up through 8192 are basically just noise; this
is probably because we don't actually have that many
distinct trees in git.git). But for log-S, we get a definite
speed improvement as the cache grows, but the improvements
are lost as cache size grows and the linear LRU management
starts to dominate.

Here's the same thing run against linux.git:

MAX_DELTA_CACHE log-raw log-S
--------------- --------- ----------
256 0m40.987s 5m13.216s
512 0m37.949s 5m03.243s
1024 0m35.977s 4m50.580s
2048 0m33.855s 4m39.818s
4096 0m32.913s 4m47.299s*
8192 0m32.176s* 5m14.650s
16384 0m32.185s 6m31.625s
32768 0m38.056s 9m31.136s
65536 1m30.518s 17m38.549s

The pattern is similar, though the effect in log-raw is more
pronounced here. The times dip down in the middle, and then
go back up as we keep growing.

So we know there's a problem. What's the solution?

The obvious one is to improve the data structure to avoid
walking over tree entries during the looking-for-blobs
traversal. We can do this by keeping _two_ LRU lists: one
for blobs, and one for other objects. We drop items from the
blob LRU first, and then from the tree LRU (if necessary).

Here's git.git using that strategy:

MAX_DELTA_CACHE log-raw log-S
--------------- --------- ----------
256 0m02.264s 0m12.830s
512 0m02.201s 0m10.771s
1024 0m02.181s 0m08.593s
2048 0m02.205s 0m07.116s
4096 0m02.158s 0m06.537s*
8192 0m02.213s 0m07.246s
16384 0m02.155s* 0m10.975s
32768 0m02.159s 0m16.047s
65536 0m02.181s 0m16.992s

The upswing on log-raw is gone completely. But log-S still
has it (albeit much better than without this strategy).
Let's see what linux.git shows:

MAX_DELTA_CACHE log-raw log-S
--------------- --------- ---------
256 0m42.519s 5m14.654s
512 0m39.106s 5m04.708s
1024 0m36.802s 4m51.454s
2048 0m34.685s 4m39.378s*
4096 0m33.663s 4m44.047s
8192 0m33.157s 4m50.644s
16384 0m33.090s* 4m49.648s
32768 0m33.458s 4m53.371s
65536 0m33.563s 5m04.580s

The results are similar. The tree-only case again performs
well (not surprising; we're literally just dropping the one
useless walk, and not otherwise changing the cache eviction
strategy at all). But the log-S case again does a bit worse
as the cache grows (though possibly that's within the noise,
which is much larger for this case).

Perhaps this is an indication that the "remove blobs first"
strategy is not actually optimal. The intent of it is to
avoid blowing out the tree cache when we see large blobs,
but it also means we'll throw away useful, recent blobs in
favor of older trees.

Let's run the same numbers without caring about object type
at all (i.e., one LRU list, and always evicting whatever is
at the head, regardless of type).

Here's git.git:

MAX_DELTA_CACHE log-raw log-S
--------------- --------- ---------
256 0m02.227s 0m12.821s
512 0m02.143s 0m10.602s
1024 0m02.127s 0m08.642s
2048 0m02.148s 0m07.123s
4096 0m02.194s 0m06.448s*
8192 0m02.239s 0m06.504s
16384 0m02.144s* 0m06.502s
32768 0m02.202s 0m06.622s
65536 0m02.230s 0m06.677s

Much smoother; there's no dramatic upswing as we increase
the cache size (some remains, though it's small enough that
it's mostly run-to-run noise. E.g., in the log-raw case,
note how 8192 is 50-100ms higher than its neighbors). Note
also that we stop getting any real benefit for log-S after
about 4096 entries; that number will depend on the size of
the repository, the size of the blob entries, and the memory
limit of the cache.

Let's see what linux.git shows for the same strategy:

MAX_DELTA_CACHE log-raw log-S
--------------- --------- ---------
256 0m41.661s 5m12.410s
512 0m39.547s 5m07.920s
1024 0m37.054s 4m54.666s
2048 0m35.871s 4m41.194s*
4096 0m34.646s 4m51.648s
8192 0m33.881s 4m55.342s
16384 0m35.190s 5m00.122s
32768 0m35.060s 4m58.851s
65536 0m33.311s* 4m51.420s

It's similarly good. As with the "separate blob LRU"
strategy, there's a lot of noise on the log-S run here. But
it's certainly not any worse, is possibly a bit better, and
the improvement over "separate blob LRU" on the git.git case
is dramatic.

So it seems like a clear winner, and that's what this patch
implements.

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

delta_base_cache: use list.h for LRUJeff King Mon, 22 Aug 2016 21:59:42 +0000 (17:59 -0400)

delta_base_cache: use list.h for LRU

We keep an LRU list of entries for when we need to drop
something from an over-full cache. The list is implemented
as a circular doubly-linked list, which is exactly what
list.h provides. We can save a few lines by using the list.h
macros and functions. More importantly, this makes the code
easier to follow, as the reader sees explicit concepts like
"list_add_tail()" instead of pointer manipulation.

As a bonus, the list_entry() macro lets us place the lru
pointers anywhere inside the delta_base_cache_entry struct
(as opposed to just casting the pointer, which requires it
at the front of the struct). This will be useful in later
patches when we need to place other items at the front of
the struct (e.g., our hashmap implementation requires this).

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

release_delta_base_cache: reuse existing detach functionJeff King Mon, 22 Aug 2016 21:57:58 +0000 (17:57 -0400)

release_delta_base_cache: reuse existing detach function

This function drops an entry entirely from the cache,
meaning that aside from the freeing of the buffer, it is
exactly equivalent to detach_delta_base_cache_entry(). Let's
build on top of the detach function, which shortens the code
and will make it simpler when we change out the underlying
storage in future patches.

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

clear_delta_base_cache_entry: use a more descriptive... Jeff King Mon, 22 Aug 2016 21:57:53 +0000 (17:57 -0400)

clear_delta_base_cache_entry: use a more descriptive name

The delta base cache entries are stored in a fixed-length
hash table. So the way to remove an entry is to "clear" the
slot in the table, and that is what this function does.

However, the name is a leaky abstraction. If we were to
change the hash table implementation, it would no longer be
about "clearing". We should name it after _what_ it does,
not _how_ it does it. I.e., something like "remove" instead
of "clear".

But that does not tell the whole story, either. The subtle
thing about this function is that it removes the entry, but
does not free the entry data. So a more descriptive name is
"detach"; we give ownership of the data buffer to the
caller, and remove any other resources.

This patch uses the name detach_delta_base_cache_entry().
We could further model this after functions like
strbuf_detach(), which pass back all of the detached
information. However, since there are so many bits of
information in the struct (the data, the size, the type),
and so few callers (only one), it's not worth that
awkwardness. The name change and a comment can make the
intent clear.

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

cache_or_unpack_entry: drop keep_cache parameterJeff King Mon, 22 Aug 2016 21:57:45 +0000 (17:57 -0400)

cache_or_unpack_entry: drop keep_cache parameter

There is only one caller of cache_or_unpack_entry() and it
always passes 1 for the keep_cache parameter. We can
simplify it by dropping the "!keep_cache" case.

Another call, which did pass 0, was dropped in abe601b
(sha1_file: remove recursion in unpack_entry, 2013-03-27),
as unpack_entry() now does more complicated things than a
simple unpack when there is a cache miss.

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

doc: mention `git -c` in git-config(1)David Glasser Tue, 23 Aug 2016 17:33:21 +0000 (10:33 -0700)

doc: mention `git -c` in git-config(1)

Signed-off-by: David Glasser <glasser@davidglasser.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mingw: ensure temporary file handles are not inherited... Ben Wijen Mon, 22 Aug 2016 12:47:55 +0000 (14:47 +0200)

mingw: ensure temporary file handles are not inherited by child processes

When the index is locked and child processes inherit the handle to
said lock and the parent process wants to remove the lock before the
child process exits, on Windows there is a problem: it won't work
because files cannot be deleted if a process holds a handle on them.
The symptom:

Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed.
Should I try again? (y/n)

Spawning child processes with bInheritHandles==FALSE would not work
because no file handles would be inherited, not even the hStdXxx
handles in STARTUPINFO (stdin/stdout/stderr).

Opening every file with O_NOINHERIT does not work, either, as e.g.
git-upload-pack expects inherited file handles.

This leaves us with the only way out: creating temp files with the
O_NOINHERIT flag. This flag is Windows-specific, however. For our
purposes, it is equivalent to O_CLOEXEC (which does not exist on
Windows), so let's just open temporary files with the O_CLOEXEC flag and
map that flag to O_NOINHERIT on Windows.

As Eric Wong pointed out, we need to be careful to handle the case where
the Linux headers used to compile Git support O_CLOEXEC but the Linux
kernel used to run Git does not: it returns an EINVAL.

This fixes the test that we just introduced to demonstrate the problem.

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

l10n: ko.po: Update Korean translationChangwoo Ryu Sun, 21 Aug 2016 13:44:00 +0000 (22:44 +0900)

l10n: ko.po: Update Korean translation

Signed-off-by: Changwoo Ryu <cwryu@debian.org>

Git 2.10-rc1 v2.10.0-rc1Junio C Hamano Fri, 19 Aug 2016 22:39:33 +0000 (15:39 -0700)

Git 2.10-rc1

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

Merge branch 'lt/gpg-show-long-key-in-signature-verific... Junio C Hamano Fri, 19 Aug 2016 22:34:16 +0000 (15:34 -0700)

Merge branch 'lt/gpg-show-long-key-in-signature-verification'

"git log --show-signature" and other commands that display the
verification status of PGP signature now shows the longer key-id,
as 32-bit key-id is so last century.

* lt/gpg-show-long-key-in-signature-verification:
gpg-interface: prefer "long" key format output when verifying pgp signatures

Merge branch 'ab/hooks'Junio C Hamano Fri, 19 Aug 2016 22:34:16 +0000 (15:34 -0700)

Merge branch 'ab/hooks'

"git rev-parse --git-path hooks/<hook>" learned to take
core.hooksPath configuration variable (introduced during 2.9 cycle)
into account.

* ab/hooks:
rev-parse: respect core.hooksPath in --git-path

Merge branch 'jk/difftool-command-not-found'Junio C Hamano Fri, 19 Aug 2016 22:34:15 +0000 (15:34 -0700)

Merge branch 'jk/difftool-command-not-found'

"git difftool" by default ignores the error exit from the backend
commands it spawns, because often they signal that they found
differences by exiting with a non-zero status code just like "diff"
does; the exit status codes 126 and above however are special in
that they are used to signal that the command is not executable,
does not exist, or killed by a signal. "git difftool" has been
taught to notice these exit status codes.

* jk/difftool-command-not-found:
difftool: always honor fatal error exit codes

Merge branch 'sb/checkout-explit-detach-no-advice'Junio C Hamano Fri, 19 Aug 2016 22:34:15 +0000 (15:34 -0700)

Merge branch 'sb/checkout-explit-detach-no-advice'

"git checkout --detach <branch>" used to give the same advice
message as that is issued when "git checkout <tag>" (or anything
that is not a branch name) is given, but asking with "--detach" is
an explicit enough sign that the user knows what is going on. The
advice message has been squelched in this case.

* sb/checkout-explit-detach-no-advice:
checkout: do not mention detach advice for explicit --detach option

Merge branch 'tb/t0027-raciness-fix'Junio C Hamano Fri, 19 Aug 2016 22:34:14 +0000 (15:34 -0700)

Merge branch 'tb/t0027-raciness-fix'

The t0027 test for CRLF conversion was timing dependent and flaky.

* tb/t0027-raciness-fix:
convert: Correct NNO tests and missing `LF will be replaced by CRLF`

Merge branch 'rs/pull-signed-tag'Junio C Hamano Fri, 19 Aug 2016 22:34:13 +0000 (15:34 -0700)

Merge branch 'rs/pull-signed-tag'

When "git merge-recursive" works on history with many criss-cross
merges in "verbose" mode, the names the command assigns to the
virtual merge bases could have overwritten each other by unintended
reuse of the same piece of memory.

* rs/pull-signed-tag:
commit: use FLEX_ARRAY in struct merge_remote_desc
merge-recursive: fix verbose output for multiple base trees
commit: factor out set_merge_remote_desc()
commit: use xstrdup() in get_merge_parent()

Revert "display HTML in default browser using Windows... Johannes Schindelin Fri, 19 Aug 2016 08:39:38 +0000 (10:39 +0200)

Revert "display HTML in default browser using Windows' shell API"

Since 4804aab (help (Windows): Display HTML in default browser using
Windows' shell API, 2008-07-13), Git for Windows used to call
`ShellExecute()` to launch the default Windows handler for `.html`
files.

The idea was to avoid going through a shell script, for performance
reasons.

However, this change ignores the `help.browser` config setting. Together
with browsing help not being a performance-critical operation, let's
just revert that patch.

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

t6026-merge-attr: child processes must not inherit... Ben Wijen Thu, 18 Aug 2016 14:51:12 +0000 (16:51 +0200)

t6026-merge-attr: child processes must not inherit index.lock handles

On Windows, a file cannot be removed unless all file handles to it have
been released. Hence it is particularly important to close handles when
spawning children (which would probably not even know that they hold on
to those handles).

The example chosen for this test is a custom merge driver that indeed
has no idea that it blocks the deletion of index.lock. The full use case
is a daemon that lives on after the merge, with subsequent invocations
handing off to the daemon, thereby avoiding hefty start-up costs. We
simulate this behavior by simply sleeping one second.

Note that the test only fails on Windows, due to the file locking issue.
Since we have no way to say "expect failure with MINGW, success
otherwise", we simply skip this test on Windows for now.

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

clone: recursive and reference option triggers submodul... Stefan Beller Wed, 17 Aug 2016 22:45:35 +0000 (15:45 -0700)

clone: recursive and reference option triggers submodule alternates

When `--recursive` and `--reference` is given, it is reasonable to
expect that the submodules are created with references to the submodules
of the given alternate for the superproject.

An initial attempt to do this was presented to the mailing list, which
used flags that are passed around ("--super-reference") that instructed
the submodule clone to look for a reference in the submodules of the
referenced superproject. This is not well thought out, as any further
`submodule update` should also respect the initial setup.

When a new submodule is added to the superproject and the alternate
of the superproject does not know about that submodule yet, we rather
error out informing the user instead of being unclear if we did or did
not use a submodules alternate.

To solve this problem introduce new options that store the configuration
for what the user wanted originally.

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

RelNotes: final batch of topics before -rc1Junio C Hamano Wed, 17 Aug 2016 21:09:17 +0000 (14:09 -0700)

RelNotes: final batch of topics before -rc1

Merge branch 'js/test-lint-pathname'Junio C Hamano Wed, 17 Aug 2016 21:07:48 +0000 (14:07 -0700)

Merge branch 'js/test-lint-pathname'

The "t/" hierarchy is prone to get an unusual pathname; "make test"
has been taught to make sure they do not contain paths that cannot
be checked out on Windows (and the mechanism can be reusable to
catch pathnames that are not portable to other platforms as need
arises).

* js/test-lint-pathname:
t/Makefile: ensure that paths are valid on platforms we care

Merge branch 'sg/reflog-past-root'Junio C Hamano Wed, 17 Aug 2016 21:07:48 +0000 (14:07 -0700)

Merge branch 'sg/reflog-past-root'

A small test clean-up for a topic introduced in v2.9.1 and later.

* sg/reflog-past-root:
t1410: remove superfluous 'git reflog' from the 'walk past root' test

Merge branch 'rs/mailinfo-lib'Junio C Hamano Wed, 17 Aug 2016 21:07:47 +0000 (14:07 -0700)

Merge branch 'rs/mailinfo-lib'

Small code clean-up.

* rs/mailinfo-lib:
mailinfo: recycle strbuf in check_header()

Merge branch 'jk/tighten-alloc'Junio C Hamano Wed, 17 Aug 2016 21:07:46 +0000 (14:07 -0700)

Merge branch 'jk/tighten-alloc'

Small code and comment clean-up.

* jk/tighten-alloc:
receive-pack: use FLEX_ALLOC_MEM in queue_command()
correct FLEXPTR_* example in comment

Merge branch 'va/i18n'Junio C Hamano Wed, 17 Aug 2016 21:07:45 +0000 (14:07 -0700)

Merge branch 'va/i18n'

A handful of tests that were broken under gettext-poison build have
been fixed.

* va/i18n:
t7411: become resilient to GETTEXT_POISON
t5520: become resilient to GETTEXT_POISON
t3404: become resilient to GETTEXT_POISON

git-multimail: update to release 1.4.0Matthieu Moy Wed, 17 Aug 2016 06:41:16 +0000 (08:41 +0200)

git-multimail: update to release 1.4.0

Changes are described in CHANGES.

Contributions-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Contributions-by: Irfan Adilovic <irfanadilovic@gmail.com>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

relnotes: redo the description of text=auto fixJunio C Hamano Wed, 17 Aug 2016 17:18:59 +0000 (10:18 -0700)

relnotes: redo the description of text=auto fix

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

SubmittingPatches: document how to reference previous... Heiko Voigt Thu, 28 Jul 2016 12:55:14 +0000 (14:55 +0200)

SubmittingPatches: document how to reference previous commits

To reference previous commits people used to put just the
abbreviated SHA-1 into commit messages. This is what has evolved as
a more stable format for referencing commits. So lets document it
for everyone to look-up when needed.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'lt/gpg-show-long-key-in-signature-verific... Junio C Hamano Tue, 16 Aug 2016 22:04:13 +0000 (15:04 -0700)

Merge branch 'lt/gpg-show-long-key-in-signature-verification-maint' into lt/gpg-show-long-key-in-signature-verification

Linus's original was rebased to apply to the maintenance track just
in case binary distributors that are stuck in the past want to take
it to their older codebase. Let's merge it up to more modern
codebase that has Peff's gpg-interface clean-up topic that appeared
after Git 2.9 was tagged.

* lt/gpg-show-long-key-in-signature-verification-maint:
gpg-interface: prefer "long" key format output when verifying pgp signatures

gpg-interface: prefer "long" key format output when... Linus Torvalds Tue, 16 Aug 2016 20:10:24 +0000 (13:10 -0700)

gpg-interface: prefer "long" key format output when verifying pgp signatures

Yes, gpg2 already uses the long format by default, but most
distributions seem to still have "gpg" be the older 1.x version due to
compatibility reasons. And older versions of gpg only show the 32-bit
short ID, which is quite insecure.

This doesn't actually matter for the _verification_ itself: if the
verification passes, the pgp signature is good. But if you don't
actually have the key yet, and want to fetch it, or you want to check
exactly which key was used for verification and want to check it, we
should specify the key with more precision.

In fact, we should preferentially specify the whole key fingerprint, but
gpg doesn't actually support that. Which is really quite sad.

Showing the "long" format improves things to at least show 64 bits of
the fingerprint. That's a lot better, even if it's not perfect.

This change the log format for "git log --show-signature" from

commit 2376d31787760af598db23bb3982a57419854e5c
merged tag 'v2.9.3'
gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT using RSA key ID 96AFE6CB
gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
gpg: aka "Junio C Hamano <jch@google.com>"
gpg: aka "Junio C Hamano <junio@pobox.com>"
Merge: 2807cd7b25af e0c1ceafc5be
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Aug 12 10:02:18 2016 -0700

to

commit 2376d31787760af598db23bb3982a57419854e5c
merged tag 'v2.9.3'
gpg: Signature made Fri 12 Aug 2016 09:17:59 AM PDT
gpg: using RSA key B0B5E88696AFE6CB
gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
gpg: aka "Junio C Hamano <jch@google.com>"
gpg: aka "Junio C Hamano <junio@pobox.com>"
Merge: 2807cd7b25af e0c1ceafc5be
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Aug 12 10:02:18 2016 -0700

(note the longer key ID, but also the reflowing of the text) and also
changes the format in the merge messages when merging a signed
tag.

If you already use gpg2 (either because it's installed by default, or
because you have set your gpg_program configuration to point to gpg2),
that already used the long format, you'll also see a change: it will now
have the same formatting as gpg 1.x, and the verification string looks
something like

gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT
gpg: using RSA key 79BE3E4300411886
gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" [ultimate]

where it used to be on one line:

gpg: Signature made Sun 24 Jul 2016 12:24:02 PM PDT using RSA key ID 79BE3E4300411886
gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" [ultimate]

so there is certainly a chance this could break some automated scripting.
But the 32-bit key ID's really are broken. Also note that because of the
differences between gpg-1.x and gpg-2.x, hopefully any scripted key ID
parsing code (if such code exists) is already flexible enough to not care.

This was triggered by the fact that the "evil32" project keys ended up
leaking to the public key servers, so now there are 32-bit aliases for
just about every open source developer that you can easily get by
mistake if you use the 32-bit short ID format.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rev-parse: respect core.hooksPath in --git-pathJohannes Schindelin Tue, 16 Aug 2016 13:14:27 +0000 (15:14 +0200)

rev-parse: respect core.hooksPath in --git-path

The idea of the --git-path option is not only to avoid having to
prefix paths with the output of --git-dir all the time, but also to
respect overrides for specific common paths inside the .git directory
(e.g. `git rev-parse --git-path objects` will report the value of the
environment variable GIT_OBJECT_DIRECTORY, if set).

When introducing the core.hooksPath setting, we forgot to adjust
git_path() accordingly. This patch fixes that.

While at it, revert the special-casing of core.hooksPath in
run-command.c, as it is now no longer needed.

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

t/Makefile: ensure that paths are valid on platforms... Johannes Schindelin Tue, 16 Aug 2016 15:13:25 +0000 (17:13 +0200)

t/Makefile: ensure that paths are valid on platforms we care

Some pathnames that are okay on ext4 and on HFS+ cannot be checked
out on Windows. Tests that want to see operations on such paths on
filesystems that support them must do so behind appropriate test
prerequisites, and must not include them in the source tree (instead
they should create them when they run). Otherwise, the source tree
cannot even be checked out.

Make sure that double-quotes, asterisk, colon, greater/less-than,
question-mark, backslash, tab, vertical-bar, as well as any non-ASCII
characters never appear in the pathnames with a new test-lint-* target
as part of a `make test`. To that end, we call `git ls-files` (ensuring
that the paths are quoted properly), relying on the fact that paths
containing non-ASCII characters are quoted within double-quotes.

In case that the source code does not actually live in a Git
repository (e.g. when extracted from a .zip file), or that the `git`
executable cannot be executed, we simply ignore the error for now; In
that case, our trusty Continuous Integration will be the last line of
defense and catch any problematic file name.

Noticed when a topic wanted to add a pathname with '>' in it. A
check like this will prevent a similar problems from happening in the
future.

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

clone: implement optional referencesStefan Beller Mon, 15 Aug 2016 21:53:26 +0000 (14:53 -0700)

clone: implement optional references

In a later patch we want to try to create alternates for submodules,
but they might not exist in the referenced superproject. So add a way
to skip the non existing references and report them.

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

clone: clarify option_reference as requiredStefan Beller Mon, 15 Aug 2016 21:53:25 +0000 (14:53 -0700)

clone: clarify option_reference as required

In the next patch we introduce optional references; To better distinguish
between optional and required references we rename the variable.

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

clone: factor out checking for an alternate pathStefan Beller Mon, 15 Aug 2016 21:53:24 +0000 (14:53 -0700)

clone: factor out checking for an alternate path

In a later patch we want to determine if a path is suitable as an
alternate from other commands than builtin/clone. Move the checking
functionality of `add_one_reference` to `compute_alternate_path` that is
defined in cache.h.

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

difftool: always honor fatal error exit codesJohn Keeping Mon, 15 Aug 2016 21:54:39 +0000 (22:54 +0100)

difftool: always honor fatal error exit codes

At the moment difftool's "trust exit code" logic always suppresses the
exit status of the diff utility we invoke. This is useful because we
don't want to exit just because diff returned "1" because the files
differ, but it's confusing if the shell returns an error because the
selected diff utility is not found.

POSIX specifies 127 as the exit status for "command not found", 126 for
"command found but is not executable" and values greater than 128 if the
command terminated because it received a signal [1] and at least bash
and dash follow this specification, while diff utilities generally use
"1" for the exit status we want to ignore.

Handle any value of 126 or greater as a special value indicating that
some form of fatal error occurred.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_02

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

checkout: do not mention detach advice for explicit... Stefan Beller Mon, 15 Aug 2016 18:40:21 +0000 (11:40 -0700)

checkout: do not mention detach advice for explicit --detach option

When a user asked for a detached HEAD specifically with `--detach`,
we do not need to give advice on what a detached HEAD state entails as
we can assume they know what they're getting into as they asked for it.

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

Relnotes: decribe the updates to the "text=auto" attributeJunio C Hamano Mon, 15 Aug 2016 17:20:38 +0000 (10:20 -0700)

Relnotes: decribe the updates to the "text=auto" attribute

Helped-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1410: remove superfluous 'git reflog' from the 'walk... SZEDER Gábor Sun, 14 Aug 2016 23:28:53 +0000 (01:28 +0200)

t1410: remove superfluous 'git reflog' from the 'walk past root' test

The test added in 71abeb753fa8 (reflog: continue walking the reflog
past root commits, 2016-06-03) contains an unnecessary 'git reflog'
execution, which was part of my debug/tracing instrumentation that I
somehow didn't manage to remove before submitting.

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

l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed)Jiang Xin Mon, 15 Aug 2016 14:45:20 +0000 (22:45 +0800)

l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed)

Generate po/git.pot from v2.10.0-rc0 for git v2.10.0 l10n round 1.

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

Git 2.10-rc0 v2.10.0-rc0Junio C Hamano Sun, 14 Aug 2016 21:48:06 +0000 (14:48 -0700)

Git 2.10-rc0

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

convert: Correct NNO tests and missing `LF will be... Torsten Bögershausen Sat, 13 Aug 2016 21:29:27 +0000 (23:29 +0200)

convert: Correct NNO tests and missing `LF will be replaced by CRLF`

When a non-reversible CRLF conversion is done in "git add",
a warning is printed on stderr (or Git dies, depending on checksafe)

The function commit_chk_wrnNNO() in t0027 was written to test this,
but did the wrong thing: Instead of looking at the warning
from "git add", it looked at the warning from "git commit".

This is racy because "git commit" may not have to do CRLF conversion
at all if it can use the sha1 value from the index (which depends on
whether "add" and "commit" run in a single second).

Correct t0027 and replace the commit for each and every file with a commit
of all files in one go.
The function commit_chk_wrnNNO() should be renamed in a separate commit.

Now that t0027 does the right thing, it detects a bug in covert.c:
This sequence should generate the warning `LF will be replaced by CRLF`,
but does not:

$ git init
$ git config core.autocrlf false
$ printf "Line\r\n" >file
$ git add file
$ git commit -m "commit with CRLF"
$ git config core.autocrlf true
$ printf "Line\n" >file
$ git add file

"git add" calls crlf_to_git() in convert.c, which calls check_safe_crlf().
When has_cr_in_index(path) is true, crlf_to_git() returns too early and
check_safe_crlf() is not called at all.

Factor out the code which determines if "git checkout" converts LF->CRLF
into will_convert_lf_to_crlf().

Update the logic around check_safe_crlf() and "simulate" the possible
LF->CRLF conversion at "git checkout" with help of will_convert_lf_to_crlf().
Thanks to Jeff King <peff@peff.net> for analyzing t0027.

Reported-By: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

receive-pack: use FLEX_ALLOC_MEM in queue_command()René Scharfe Sat, 13 Aug 2016 15:38:56 +0000 (17:38 +0200)

receive-pack: use FLEX_ALLOC_MEM in queue_command()

Use the macro FLEX_ALLOC_MEM instead of open-coding it. This shortens
and simplifies the code a bit.

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

commit: use FLEX_ARRAY in struct merge_remote_descRené Scharfe Sat, 13 Aug 2016 12:21:27 +0000 (14:21 +0200)

commit: use FLEX_ARRAY in struct merge_remote_desc

Convert the name member of struct merge_remote_desc to a FLEX_ARRAY and
use FLEX_ALLOC_STR to build the struct. This halves the number of
memory allocations, saves the storage for a pointer and avoids an
indirection when reading the name.

Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-recursive: fix verbose output for multiple base... René Scharfe Sat, 13 Aug 2016 12:16:04 +0000 (14:16 +0200)

merge-recursive: fix verbose output for multiple base trees

One of the indirect callers of make_virtual_commit() passes the result of
oid_to_hex() as the name, i.e. a pointer to a static buffer. Since the
function uses that string pointer directly in building a struct
merge_remote_desc, multiple entries can end up sharing the same name
inadvertently.

Fix that by calling set_merge_remote_desc(), which creates a copy of the
string, instead of building the struct by hand.

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

commit: factor out set_merge_remote_desc()René Scharfe Sat, 13 Aug 2016 12:11:27 +0000 (14:11 +0200)

commit: factor out set_merge_remote_desc()

Export a helper function for allocating, populating and attaching a
merge_remote_desc to a commit.

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

commit: use xstrdup() in get_merge_parent()René Scharfe Sat, 13 Aug 2016 12:09:49 +0000 (14:09 +0200)

commit: use xstrdup() in get_merge_parent()

Handle allocation errors for the name member just like we already do
for the struct merge_remote_desc itself.

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

mailinfo: recycle strbuf in check_header()René Scharfe Sat, 13 Aug 2016 09:05:42 +0000 (11:05 +0200)

mailinfo: recycle strbuf in check_header()

handle_message_id() duplicates the contents of the strbuf that is passed
to it. Its only caller proceeds to release the strbuf immediately after
that. Reuse it instead and make that change of object ownership more
obvious by inlining this short function.

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

correct FLEXPTR_* example in commentRené Scharfe Sat, 13 Aug 2016 09:01:21 +0000 (11:01 +0200)

correct FLEXPTR_* example in comment

This section is about "The FLEXPTR_* variants", so use FLEXPTR_ALLOC_STR
in the example.

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

doc: revisions: sort examples and fix alignment of... Philip Oakley Fri, 12 Aug 2016 23:45:22 +0000 (00:45 +0100)

doc: revisions: sort examples and fix alignment of the unchanged

The previous commit adjusted the column alignment for revision
examples which show expansion. Fix the unchanged examples and sort
those that show expansions to the end of the list.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

doc: revisions: show revision expansion in examplesPhilip Oakley Fri, 12 Aug 2016 23:45:21 +0000 (00:45 +0100)

doc: revisions: show revision expansion in examples

The revisions examples show the revison arguments and the selected
commits, but do not show the intermediate step of the expansion of
the special 'range' notations. Extend the examples, including an
all-parents multi-parent merge commit example.

Sort the examples and fix the alignment for those unaffected
in the next commit.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>