Comments about misbehaving FreeBSD shells have been clarified with
the version number (9.x and before are broken, newer ones are OK).

* em/newer-freebsd-shells-are-fine-with-returns:
  rebase: update comment about FreeBSD /bin/sh

"git status" used to say "working directory" when it meant "working
tree".

* lv/status-say-working-tree-not-directory:
  Use "working tree" instead of "working directory" for git status

Build improvements for gnome-keyring (in contrib/)

* nb/gnome-keyring-build:
  gnome-keyring: Don't hard-code pkg-config executable

"git update-index --add --chmod=+x file" may be usable as an escape
hatch, but not a friendly thing to force for people who do need to
use it regularly.  "git add --chmod=+x file" can be used instead.

* et/add-chmod-x:
  add: add --chmod=+x / --chmod=-x options

A codepath that used alloca(3) to place an unbounded amount of data
on the stack has been updated to avoid doing so.

* jk/avoid-unbounded-alloca:
  tree-diff: avoid alloca for large allocations

A compilation fix.

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

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

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

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

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

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

* dn/gpg-doc:
  Documentation: GPG capitalization

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Commit 9f50d32b introduced a fix for FreeBSD /bin/sh misbehaviour
when dot-sourcing a file containing "return" statements outside of
any function, from a function in another shell script. That issue
affects FreeBSD 9.x, and is not present in the /bin/sh in FreeBSD
10.3 and later. Update the comment to clarify this.

The example from 9f50d32b's commit message produces the expected output
on FreeBSD 10.3 and -CURRENT (the upcoming 11.0):

% sh script1.sh
only this line should show
%
Signed-off-by: NEd Maste <emaste@freebsd.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When "GPG" is used in a sentence it is now consistently capitalized.
When referring to the binary it is left as "gpg".
Signed-off-by: NDavid Nicolson <david.nicolson@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add example usage to the git-svn documentation.
Reported-by: NJoseph Pecoraro <pecoraro@apple.com>
Signed-off-by: NAlfred Perlstein <alfred@freebsd.org>
Reviewed-by: NEric Wong <e@80x24.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Helpful if your pkg-config executable has a prefix based on the
architecture, for example.
Signed-off-by: NHeiko Becker <heirecka@exherbo.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

l10n-2.9.0-rc0

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

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

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

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

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

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

test fixes.

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

A test fix.

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

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

    def foo
      do_foo_stuff()

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

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

Disable the heuristics by default, and resurrect the documentation
for the option and the configuration variables, while clearly
marking the feature as still experimental.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Translate 104 new messages came from git.pot update in f517e50d
(l10n: git.pot: v2.9.0 round 1 (104 new, 37 removed)).
Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com>

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

If the next change is an appended chunk we abort the search early in
get_func_line(), however, because its line number is out of range.  Fix
that by searching from the end of the pre-image in that case instead.
Reported-by: NJunio C Hamano <gitster@pobox.com>
Signed-off-by: NRene Scharfe <l.s.r@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Working directory can be easily confused with the current directory.
In one of my patches I already updated the usage of working directory
with working tree for the man page but I noticed that git status also
uses this incorrect term.
Signed-off-by: NLars Vogel <Lars.Vogel@vogella.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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

	grep '[[:alpha:]]*\.[[:alpha:]]*::$' config.txt | \
	sed -e 's/::$//' -e 's/\./\\\\./' | \
	xargs -iP perl -pi -e "s/\'P\'/\`P\`/g" ./*.txt
Signed-off-by: NTom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: NErwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: NSamuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: NMatthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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

One of the main purposes is to stick to the CodingGuidelines as possible so
that people writting new documentation by mimicking the existing are more likely
to have it right (even if they didn't read the CodingGuidelines).
Signed-off-by: NTom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: NErwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: NSamuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: NMatthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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

One of the main purposes is to stick to the CodingGuidelines as possible so
that people writting new documentation by mimicking the existing are more likely
to have it right (even if they didn't read the CodingGuidelines).
Signed-off-by: NTom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: NErwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: NSamuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: NMatthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Make the guideline text that we want for our documentation clearer.
Signed-off-by: NTom Russello <tom.russello@grenoble-inp.org>
Signed-off-by: NErwan Mathoniere <erwan.mathoniere@grenoble-inp.org>
Signed-off-by: NSamuel Groot <samuel.groot@grenoble-inp.org>
Signed-off-by: NMatthieu Moy <matthieu.moy@grenoble-inp.fr>
Reviewed-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Commit 72441af7 (tree-diff: rework diff_tree() to generate
diffs for multiparent cases as well, 2014-04-07) introduced
the use of alloca so that the common cases of commits with 1
or 2 parents would not be adversely affected by going
through the multi-parent code.

However, our xalloca is not ideal when the number of parents
grows very large:

  1. If the requested size is too large for our stack,
     alloca() has no way to tell us, and we simply segfault
     while trying to access the memory.

  2. It does not use our usual memory_limit_check() logic.

I measured, and alloca is indeed buying us a very small
speedup over xmalloc()/free(). So we'd want to keep
something like it.

This patch simply puts a conditional in place at each
callsite: we use alloca for common known-small numbers of
parents, and otherwise use the heap. We are technically
still vulnerable to (1), but no more so than if we simply
put a few dozen bytes on the stack, which we must do all the
time anyway. And likewise, we technically miss a memory
limit check if it is tiny, but such a limit is pointless.

An alternative to this would be implement something like:

  struct tree *tp, tp_fallback[2];
  if (nparent <= ARRAY_SIZE(tp_fallback))
          tp = tp_fallback;
  else
	  ALLOC_ARRAY(tp, nparent);
  ...
  if (tp != tp_fallback)
	  free(tp);

That would let us drop our xalloca() portability code
entirely. But in my measurements, this seemed to perform
slightly worse than the xalloca solution.

Note in the example above, and in the patch below, I've used
ALLOC_ARRAY() to replace the manual xmalloc(nr * sizeof(*x)).
Besides being shorter, this has the bonus that one cannot
accidentally overflow a size_t during that computation.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>