Add the option -W/--function-context to git diff.  It is similar to
the same option of git grep and expands the context of change hunks
so that the whole surrounding function is shown.  This "natural"
context can allow changes to be understood better.

Note: GNU patch doesn't like diffs generated with the new option;
it seems to expect context lines to be the same before and after
changes.  git apply doesn't complain.

This implementation has the same shortcoming as the one in grep,
namely that there is no way to explicitly find the end of a
function.  That means that a few lines of extra context are shown,
right up to the next recognized function begins.  It's already
useful in its current form, though.

The function get_func_line() in xdiff/xemit.c is extended to work
forward as well as backward to find post-context as well as
pre-context.  It returns the position of the first found matching
line.  The func_line parameter is made optional, as we don't need
it for -W.

The enhanced function is then used in xdl_emit_diff() to extend
the context as needed.  If the added context overlaps with the
next change, it is merged into the current hunk.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

* ph/format-patch-no-color:
  t4014: clean up format.thread config after each test

The threading tests turn on format.thread, but never clean
up after themselves, meaning that later tests will also have
format.thread set.

This is more annoying than most leftover config, too,
because not only does it impact the results of other tests,
but it does so non-deterministically. Threading requires the
generation of message-ids, which incorporate the current
time, meaning a slow-running test script may generate
different results from run to run.

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

* ci/forbid-unwanted-current-branch-update:
  branch --set-upstream: regression fix

The "git branch" command, while not in listing mode, calls create_branch()
even when the target branch already exists, and it does so even when it is
not interested in updating the value of the branch (i.e. the name of the
commit object that sits at the tip of the existing branch). This happens
when the command is run with "--set-upstream" option.

The earlier safety-measure to prevent "git branch -f $branch $commit" from
updating the currently checked out branch did not take it into account,
and we no longer can update the tracking information of the current branch.

Minimally fix this regression by telling the validation code if it is
called to really update the value of a potentially existing branch, or if
the caller merely is interested in updating auxiliary aspects of a branch.

Reported-and-Tested-by: Jay Soffian
Signed-off-by: Junio C Hamano <gitster@pobox.com>

1e5814f created t9160-git-svn-mergeinfo-push.sh on 11/9/7
40a1530 created t9160-git-svn-preserve-empty-dirs.sh on 11/7/20
The former test script is renumbered to t9161.

Signed-off-by: Frédéric Heitzmann <frederic.heitzmann@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

* ph/format-patch-no-color:
  format-patch: ignore ui.color

Allow git-svn to populate the svn:mergeinfo property automatically in
a narrow range of circumstances. Specifically, when dcommitting a
revision with multiple parents, all but (potentially) the first of
which have been committed to SVN in the same repository as the target
of the dcommit.

In this case, the merge info is the union of that given by each of the
parents, plus all changes introduced to the first parent by the other
parents.

In all other cases where a revision to be committed has multiple
parents, cause "git svn dcommit" to raise an error rather than
completing the commit and potentially losing history information in
the upstream SVN repository.

This behavior is disabled by default, and can be enabled by setting
the svn.pushmergeinfo config option.

[ew: minor style changes and manpage merge fix]

Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Bryan Jacobs <bjacobs@woti.com>

commit c9bfb953 (want_color: automatically fallback to color.ui,
2011-08-17) introduced a regression where format-patch produces colorized
patches when color.ui is set to "always".

In f3aafa4 (Disable color detection during format-patch, 2006-07-09),
git_format_config was taught to intercept diff.color to avoid passing it
down to git_log_config and later, git_diff_ui_config.

Teach git_format_config to intercept color.ui in the same way.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Pang Yan Han <pangyanhan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

* cb/maint-ls-files-error-report:
  t3005: do not assume a particular order of stdout and stderr of git-ls-files