Merge branch 'fc/rerere-conflict-style'

* fc/rerere-conflict-style:
  rerere: fix for merge.conflictstyle

Merge branch 'dt/api-doc-setup-gently'

* dt/api-doc-setup-gently:
  docs: document RUN_SETUP_GENTLY and clarify RUN_SETUP

Merge branch 'fc/mergetool-prompt'

mergetool.prompt used to default to 'true', always causing a confirmation
"do you really want to run the tool on this path" to be shown.

Among the two purposes the prompt serves, ignore the use case to
confirm that the user wants to view particular path with the named
tool, and make the prompt only to confirm the choice of the tool
made by autodetection and defaulting.  For those who configured the
tool explicitly, the prompt shown for the latter purpose is simply
annoying.

Strictly speaking, this is a backward incompatible change and the
users need to explicitly set the variable to 'true' if they want to
resurrect the now-ignored use case.

* fc/mergetool-prompt:
  mergetool: document the default for --[no-]prompt
  mergetool: run prompt only if guessed tool

Merge branch 'mm/mediawiki-encoding-fix'

* mm/mediawiki-encoding-fix:
  git-remote-mediawiki: fix encoding issue for UTF-8 media files
  git-remote-mediawiki: allow stop/start-ing the test server

Merge branch 'sk/tag-contains-wo-recursion'

* sk/tag-contains-wo-recursion:
  git tag --contains: avoid stack overflow

Merge branch 'ef/send-email-absolute-path-to-the-command'

* ef/send-email-absolute-path-to-the-command:
  send-email: windows drive prefix (e.g. C:) appears only at the beginning
  send-email: recognize absolute path on Windows

Merge branch 'jx/blame-align-relative-time'

"git blame" miscounted number of columns needed to show localized
timestamps, resulting in jaggy left-side-edge of the source code
lines in its output.

* jx/blame-align-relative-time:
  blame: dynamic blame_date_width for different locales
  blame: fix broken time_buf paddings in relative timestamp

Merge branch 'lr/git-run-setup-gently'

* lr/git-run-setup-gently:
  git.c: treat RUN_SETUP_GENTLY and RUN_SETUP as mutually exclusive

Merge branch 'fc/mergetools-vimdiff3'

* fc/mergetools-vimdiff3:
  mergetools: add vimdiff3 mode

Merge branch 'fc/merge-default-to-upstream'

"git merge" without argument, even when there is an upstream
defined for the current branch, refused to run until
merge.defaultToUpstream is set to true. Flip the default of that
configuration variable to true.

* fc/merge-default-to-upstream:
  merge: enable defaulttoupstream by default

Merge branch 'jk/external-diff-use-argv-array'

Code clean-up (and a bugfix which has been merged for 2.0).

* jk/external-diff-use-argv-array:
  run_external_diff: refactor cmdline setup logic
  run_external_diff: hoist common bits out of conditional
  run_external_diff: drop fflush(NULL)
  run_external_diff: clean up error handling
  run_external_diff: use an argv_array for the environment

Merge branch 'sk/svn-parse-datestamp'

* sk/svn-parse-datestamp:
  SVN.pm::parse_svn_date: allow timestamps with a single-digit hour

Merge branch 'rs/ref-update-check-errors-early'

* rs/ref-update-check-errors-early:
  commit.c: check for lock error and return early
  sequencer.c: check for lock failure and bail early in fast_forward_to

Merge branch 'nd/index-pack-one-fd-per-thread'

Enable threaded index-pack on platforms without thread-unsafe
pread() emulation.

* nd/index-pack-one-fd-per-thread:
  index-pack: work around thread-unsafe pread()

Merge branch 'ym/fix-opportunistic-index-update-race'

Read-only operations such as "git status" that internally refreshes
the index write out the refreshed index to the disk to optimize
future accesses to the working tree, but this could race with a
"read-write" operation that modify the index while it is running.
Detect such a race and avoid overwriting the index.

Duy raised a good point that we may need to do the same for the
normal writeout codepath, not just the "opportunistic" update
codepath.  While that is true, nobody sane would be running two
simultaneous operations that are clearly write-oriented competing
with each other against the same index file.  So in that sense that
can be done as a less urgent follow-up for this topic.

* ym/fix-opportunistic-index-update-race:
  read-cache.c: verify index file before we opportunistically update it
  wrapper.c: add xpread() similar to xread()

Merge branch 'mh/ref-transaction'

Update "update-ref --stdin [-z]" and then introduce a transactional
support for (multi-)reference updates.

* mh/ref-transaction: (27 commits)
  ref_transaction_commit(): work with transaction->updates in place
  struct ref_update: add a type field
  struct ref_update: add a lock field
  ref_transaction_commit(): simplify code using temporary variables
  struct ref_update: store refname as a FLEX_ARRAY
  struct ref_update: rename field "ref_name" to "refname"
  refs: remove API function update_refs()
  update-ref --stdin: reimplement using reference transactions
  refs: add a concept of a reference transaction
  update-ref --stdin: harmonize error messages
  update-ref --stdin: improve the error message for unexpected EOF
  t1400: test one mistake at a time
  update-ref --stdin -z: deprecate interpreting the empty string as zeros
  update-ref.c: extract a new function, parse_next_sha1()
  t1400: test that stdin -z update treats empty <newvalue> as zeros
  update-ref --stdin: simplify error messages for missing oldvalues
  update-ref --stdin: make error messages more consistent
  update-ref --stdin: improve error messages for invalid values
  update-ref.c: extract a new function, parse_refname()
  parse_cmd_verify(): copy old_sha1 instead of evaluating <oldvalue> twice
  ...

Merge branch 'ks/tree-diff-nway'

Instead of running N pair-wise diff-trees when inspecting a
N-parent merge, find the set of paths that were touched by walking
N+1 trees in parallel.  These set of paths can then be turned into
N pair-wise diff-tree results to be processed through rename
detections and such.  And N=2 case nicely degenerates to the usual
2-way diff-tree, which is very nice.

* ks/tree-diff-nway:
  mingw: activate alloca
  combine-diff: speed it up, by using multiparent diff tree-walker directly
  tree-diff: rework diff_tree() to generate diffs for multiparent cases as well
  Portable alloca for Git
  tree-diff: reuse base str(buf) memory on sub-tree recursion
  tree-diff: no need to call "full" diff_tree_sha1 from show_path()
  tree-diff: rework diff_tree interface to be sha1 based
  tree-diff: diff_tree() should now be static
  tree-diff: remove special-case diff-emitting code for empty-tree cases
  tree-diff: simplify tree_entry_pathcmp
  tree-diff: show_path prototype is not needed anymore
  tree-diff: rename compare_tree_entry -> tree_entry_pathcmp
  tree-diff: move all action-taking code out of compare_tree_entry()
  tree-diff: don't assume compare_tree_entry() returns -1,0,1
  tree-diff: consolidate code for emitting diffs and recursion in one place
  tree-diff: show_tree() is not needed
  tree-diff: no need to pass match to skip_uninteresting()
  tree-diff: no need to manually verify that there is no mode change for a path
  combine-diff: move changed-paths scanning logic into its own function
  combine-diff: move show_log_first logic/action out of paths scanning

Merge branch 'jc/apply-ignore-whitespace'

"--ignore-space-change" option of "git apply" ignored the
spaces at the beginning of line too aggressively, which is
inconsistent with the option of the same name "diff" and "git diff"
have.

* jc/apply-ignore-whitespace:
  apply --ignore-space-change: lines with and without leading whitespaces do not match

Merge branch 'as/grep-fullname-config'

Add a configuration variable to force --full-name to be default for
"git grep".

This may cause regressions on scripted users that do not expect
this new behaviour.

* as/grep-fullname-config:
  grep: add grep.fullName config variable

Sync with 1.9.4

Git 1.9.4

This is expected to be the final maintenance release for 1.9 series,
merging the remaining fixes that are relevant and are already in 2.0.

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

t5537: re-drop http tests

These were originally removed by 0232852 (t5537: move
http tests out to t5539, 2014-02-13). However, they were
accidentally re-added in 1ddb4d7 (Merge branch
'nd/upload-pack-shallow', 2014-03-21).

This looks like an error in manual conflict resolution.
Here's what happened:

  1. v1.9.0 shipped with the http tests in t5537.

  2. We realized that this caused problems, and built
     0232852 on top to move the tests to their own file.
     This fix made it into v1.9.1.

  3. We later had another fix in nd/upload-pack-shallow that
     also touched t5537. It was built directly on v1.9.0.

When we merged nd/upload-pack-shallow to master, we got a
conflict; it was built on a version with the http tests, but
we had since removed them. The correct resolution was to
drop the http tests and keep the new ones, but instead we
kept everything.

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

Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname' into maint

* rh/prompt-pcmode-avoid-eval-on-refname:
  git-prompt.sh: don't assume the shell expands the value of PS1

Merge branch 'mw/symlinks' into maint

* mw/symlinks:
  setup: fix windows path buffer over-stepping
  setup: don't dereference in-tree symlinks for absolute paths
  setup: add abspath_part_inside_repo() function
  t0060: add tests for prefix_path when path begins with work tree
  t0060: add test for prefix_path when path == work tree
  t0060: add test for prefix_path on symlinks via absolute paths
  t3004: add test for ls-files on symlinks via absolute paths

Git 2.0

Update draft release notes to 2.0

Hopefully for the last time ;-)

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

Git 2.0-rc4

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

RelNotes/2.0.0.txt: Fix several grammar issues, notably a lack of hyphens, double quotes, or articles

Signed-off-by: Jason St. John <jstjohn@purdue.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Revert "Merge branch 'jc/graduate-remote-hg-bzr' (early part)"

Instead of showing a warning and working as before, fail and show
the message and force immediate upgrade from their upstream
repositories when these tools are run, per request from their
primary author.

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

Merge branch 'jc/graduate-remote-hg-bzr' (early part)

* 'jc/graduate-remote-hg-bzr' (early part):
  remote-helpers: point at their upstream repositories
  contrib: remote-helpers: add move warnings (v2.0)
  Revert "Merge branch 'fc/transport-helper-sync-error-fix'"

remote-helpers: point at their upstream repositories

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

contrib: remote-helpers: add move warnings (v2.0)

The tools are now maintained out-of-tree, and they have a regression
in v2.0. It's better to start warning the users as soon as possible.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Revert "Merge branch 'fc/transport-helper-sync-error-fix'"

This reverts commit d508e4a8e2391ae2596403b6478d01cf3d5f928f,
reversing changes made to e42552135a2a396f37053a89f44952ea907870b2.

The author of the original topic says he broke the upcoming 2.0
release with something that relates to "synchronization crash
regression" while refusing to give further specifics, so this would
unfortunately be the safest option for the upcoming release.

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

Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname'

* rh/prompt-pcmode-avoid-eval-on-refname:
  git-prompt.sh: don't assume the shell expands the value of PS1

git-prompt.sh: don't assume the shell expands the value of PS1

Not all shells subject the prompt string to parameter expansion.  Test
whether the shell will expand the value of PS1, and use the result to
control whether raw ref names are included directly in PS1.

This fixes a regression introduced in commit 8976500 ("git-prompt.sh:
don't put unsanitized branch names in $PS1"):  zsh does not expand PS1
by default, but that commit assumed it did.  The bug resulted in
prompts containing the literal string '${__git_ps1_branch_name}'
instead of the actual branch name.

Reported-by: Caleb Thompson <caleb@calebthompson.io>
Signed-off-by: Richard Hansen <rhansen@bbn.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'lt/request-pull'

* lt/request-pull:
  request-pull: resurrect for-linus -> tags/for-linus DWIM

Merge branch 'jl/use-vsatisfy-correctly-for-2.0'

* jl/use-vsatisfy-correctly-for-2.0:
  git-gui: tolerate major version changes when comparing the git version

Merge git://github.com/git-l10n/git-po

* git://github.com/git-l10n/git-po:
  fr: a lot of good fixups

Merge branch 'kb/fast-hashmap'

* kb/fast-hashmap:
  Documentation/technical/api-hashmap: remove source highlighting

Documentation/technical/api-hashmap: remove source highlighting

The highlighting was pretty, but unfortunately, the failure mode
when source-highlight is not installed was that the entire code
block disappears.

See https://bugs.debian.org/745591,
    https://bugs.launchpad.net/bugs/1316810.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: tolerate major version changes when comparing the git version

Since git 2.0.0 starting git gui in a submodule using a gitfile fails with
the following error:

   No working directory ../../../<path>

   couldn't change working directory
   to "../../../<path>": no such file or
   directory

This is because "git rev-parse --show-toplevel" is only run when git gui
sees a git version of at least 1.7.0 (which is the version in which the
--show-toplevel option was introduced). But "package vsatisfies" returns
false when the major version changes, which is not what we want here.

Fix that for both places where the git version is checked using vsatisfies
by appending a '-' to the version number. This tells vsatisfies that a
change of the major version is not considered to be a problem, as long as
the new major version is larger. This is done for both the place that
caused the reported bug and another spot where the git version is tested
for another feature.

Reported-by: Chris Packham <judge.packham@gmail.com>
Reported-by: Yann Dirson <ydirson@free.fr>
Helped-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Tested-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fr: a lot of good fixups

Signed-off-by: Grégoire Paris <postmaster@greg0ire.fr>
Acked-by: Jean-Noel Avila <jn.avila@free.fr>

request-pull: resurrect for-linus -> tags/for-linus DWIM

Older versions of Git before v1.7.10 did not DWIM

    $ git pull $URL for-linus

to the tag "tags/for-linus" and the users were required to say

    $ git pull $URL tags/for-linus

instead.  Because newer versions of Git works either way,
request-pull used to show tags/for-linus when asked

    $ git request-pull origin/master $URL for-linus

The recent updates broke this and in the output we see "for-linus"
without the "tags/" prefix.

As v1.7.10 is more than 2 years old, this should matter very little
in practice, but resurrecting it is very simple.

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

Merge branch 'fc/prompt-zsh-read-from-file'

* fc/prompt-zsh-read-from-file:
  contrib: completion: fix 'eread()' namespace

contrib: completion: fix 'eread()' namespace

Otherwise it might collide with a function of the same name in the
user's environment.

Suggested-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge git://github.com/git-l10n/git-po

* git://github.com/git-l10n/git-po:
  l10n: Updated Bulgarian translation of git (1307t0f921u)

l10n: Updated Bulgarian translation of git (1307t0f921u)

Signed-off-by: Alexander Shopov <ash@kambanaria.org>

Git 2.0-rc3

Sync with 1.9.3

Git 1.9.3

The third maintenance release for Git 1.9; contains all the fixes
that are scheduled to appear in Git 2.0 since 1.9.2.

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

Sync with maint

* maint:
  shell doc: remove stray "+" in example
  Start preparing for 1.9.3

shell doc: remove stray "+" in example

The git-shell(1) manpage says

EXAMPLE
       To disable interactive logins, displaying a greeting
instead:

+

   $ chsh -s /usr/bin/git-shell
   $ mkdir $HOME/git-shell-commands
[...]

The stray "+" has been there ever since the example was added in
v1.8.3-rc0~210^2 (shell: new no-interactive-login command to print a
custom message, 2013-03-09).  The "+" sign between paragraphs is
needed in asciidoc to attach extra paragraphs to a list item but here
it is not needed and ends up rendered as a literal "+".  Remove it.

A quick search with "grep -e '<p>+' /usr/share/doc/git/html/*.html"
doesn't find any other instances of this problem.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge git://github.com/git-l10n/git-po

* 'master' of git://github.com/git-l10n/git-po:
  l10n: Fix a couple of typos in the Swedish translation

Start preparing for 1.9.3

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

Merge branch 'cl/p4-use-diff-tree' into maint

"git p4" dealing with changes in binary files were broken by a
change in 1.9 release.

* cl/p4-use-diff-tree:
  git-p4: format-patch to diff-tree change breaks binary patches

Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname' into maint

The shell prompt script (in contrib/), when using the PROMPT_COMMAND
interface, used an unsafe construct when showing the branch name in
$PS1.

* rh/prompt-pcmode-avoid-eval-on-refname:
  git-prompt.sh: don't put unsanitized branch names in $PS1

Merge branch 'km/avoid-non-function-return-in-rebase' into maint

"git rebase" used a POSIX shell construct FreeBSD /bin/sh does not
work well with.

* km/avoid-non-function-return-in-rebase:
  Revert "rebase: fix run_specific_rebase's use of "return" on FreeBSD"
  rebase: avoid non-function use of "return" on FreeBSD

Merge branch 'tb/unicode-6.3-zero-width' into maint

Some more Unicode codepoints defined in Unicode 6.3 as having zero
width have been taught to our display column counting logic.

* tb/unicode-6.3-zero-width:
  utf8.c: partially update to version 6.3

Merge branch 'km/avoid-bs-in-shell-glob' into maint

Some tests used shell constructs that did not work well on FreeBSD

* km/avoid-bs-in-shell-glob:
  test: fix t5560 on FreeBSD

Merge branch 'km/avoid-cp-a' into maint

Some tests used shell constructs that did not work well on FreeBSD

* km/avoid-cp-a:
  test: fix t7001 cp to use POSIX options

Update draft release notes for 2.0

Describe one last minute one-liner fix for regression introduced in
1.9, and fix a grave mischaracterization on a recent remote-hg/bzr
change, pointed out by Felipe.

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

Merge branch 'cl/p4-use-diff-tree'

Fixes a regression in 1.9.0 with an obviously correct single-liner.

* cl/p4-use-diff-tree:
  git-p4: format-patch to diff-tree change breaks binary patches

git-p4: format-patch to diff-tree change breaks binary patches

When applying binary patches a full index is required. format-patch
already handles this, but diff-tree needs '--full-index' argument
to always output full index. When git-p4 runs git-apply to test
the patch, git-apply rejects the patch due to abbreviated blob
object names. This is the error message git-apply emits in this
case:

    error: cannot apply binary patch to '<filename>' without full index line
    error: <filename>: patch does not apply

Signed-off-by: Tolga Ceylan <tolga.ceylan@gmail.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: Fix a couple of typos in the Swedish translation

Thanks-to: Anders Jonsson <anders.jonsson@norsjovallen.se>
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

RelNotes/2.0.0: Grammar and typo fixes

Signed-off-by: Øyvind A. Holm <sunny@sunbase.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.0-rc2

Merge branch 'mw/symlinks'

A finishing touch fix to a new change already in 'master'.

* mw/symlinks:
  setup: fix windows path buffer over-stepping

Merge branch 'km/git-svn-workaround-older-getopt-long'

* km/git-svn-workaround-older-getopt-long:
  t9117: use --prefix "" instead of --prefix=""

Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname'

* rh/prompt-pcmode-avoid-eval-on-refname:
  git-prompt.sh: don't put unsanitized branch names in $PS1

Merge branch 'mk/doc-git-gui-display-untracked'

* mk/doc-git-gui-display-untracked:
  Documentation: git-gui: describe gui.displayuntracked

docs: document RUN_SETUP_GENTLY and clarify RUN_SETUP

We only said what happens when we find the Git directory under
RUN_SETUP, without saying what happens otherwise.

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

Merge git://github.com/git-l10n/git-po

* git://github.com/git-l10n/git-po:
  l10n: de.po: improve hint for autocorrected command execution
  l10n: de.po: translate 45 new messages
  l10n: de.po: correct translation of "completed" after resolving deltas
  l10n: zh_CN.po: translate 46 new messages (2229t0f0u)
  l10n: fr translation for v2.0.0rc0 (2228t)
  l10n: Update Swedish translation (2228t0f0u)
  l10n: vi.po (2228t): Update and minor fix
  l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed)

Revert the whole "ask curl-config" topic for now

Postpone this a bit during the feature freeze and retry the effort
in the next cycle.

rerere: fix for merge.conflictstyle

If we use a different conflict style `git rerere forget` is not able
to find the matching conflict SHA-1 because the diff generated is
actually different from what `git merge` generated, due to the
XDL_MERGE_* option differences among the codepaths.

The fix is to call git_xmerge_config() so that git_xmerge_style is set
properly and the diffs match.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: de.po: improve hint for autocorrected command execution

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

l10n: de.po: translate 45 new messages

Translate 45 new messages came from git.pot update in 5e078fc
(l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Thomas Rast <tr@thomasrast.ch>

l10n: de.po: correct translation of "completed" after resolving deltas

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

Merge branch 'db/make-with-curl'

It turns out that some platforms do ship without curl-config even
though they build with the hardcoded default -lcurl and rely on it
to work.

* db/make-with-curl:
  Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR

Merge branch 'jk/external-diff-use-argv-array' (early part)

Crash fix for codepath that miscounted the necessary size for an
array when spawning an external diff program.

* 'jk/external-diff-use-argv-array' (early part):
  run_external_diff: use an argv_array for the command line

Makefile: default to -lcurl when no CURL_CONFIG or CURLDIR

The original implementation of CURL_CONFIG support did not match the
original behavior of using -lcurl when CURLDIR was not set. This broke
implementations that were lacking curl-config but did have libcurl
installed along system libraries, such as MSysGit. In other words, the
assumption that curl-config is always installed was incorrect.

Instead, if CURL_CONFIG is empty or returns an empty result (e.g. due
to curl-config being missing), use the old behavior of falling back to
-lcurl.

Signed-off-by: Dave Borowitz <dborowitz@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.0-rc1

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

git tag --contains: avoid stack overflow

In large repos, the recursion implementation of contains(commit,
commit_list) may result in a stack overflow. Replace the recursion with
a loop to fix it.

This problem is more apparent on Windows than on Linux, where the stack
is more limited by default.

See also this thread on the msysGit list:

https://groups.google.com/d/topic/msysgit/FqT6boJrb2g/discussion

[jes: re-written to imitate the original recursion more closely]

Thomas Braun pointed out several documentation shortcomings.

Tests are run only if ulimit -s is available.  This means they cannot
be run on Windows.

Signed-off-by: Jean-Jacques Lafay <jeanjacques.lafay@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: Stepan Kasal <kasal@ucw.cz>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

setup: fix windows path buffer over-stepping

Fix a buffer over-stepping issue triggered by providing an absolute path
that is similar to the work tree path.

abspath_part_inside_repo() may currently increment the path pointer by
offset_1st_component() + wtlen, which is too much, since
offset_1st_component() is a subset of wtlen.

For the *nix-style prefix '/', this does (by luck) not cause any issues,
since offset_1st_component() is 1 and there will always be a '/' or '\0'
that can "absorb" this.

In the case of DOS-style prefixes though, the offset_1st_component() is
3 and this can potentially over-step the string buffer. For example if

    work_tree = "c:/r"
    path      = "c:/rl"

Then wtlen is 4, and incrementing the path pointer by (3 + 4) would
end up 2 bytes outside a string buffer of length 6.

Similarly if

    work_tree = "c:/r"
    path      = "c:/rl/d/a"

Then (since the loop starts by also incrementing the pointer one step),
this would mean that the function would miss checking if "c:/rl/d" could
be the work_tree, arguably this is unlikely though, since it would only
be possible with symlinks on windows.

Fix this by simply avoiding to increment by offset_1st_component() and
wtlen at the same time.

Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'jk/pack-bitmap'

A last minute (and hopefully the last) fix to avoid coredumps due
to an incorrect pointer arithmetic.

* jk/pack-bitmap:
  ewah_bitmap.c: do not assume size_t and eword_t are the same size

Merge branch 'fc/transport-helper-sync-error-fix'

Make sure the marks are not written out when the transport helper
did not finish happily, to avoid leaving a marks file that is out of
sync with the reality.

* fc/transport-helper-sync-error-fix:
  t5801 (remote-helpers): cleanup environment sets
  transport-helper: fix sync issue on crashes
  transport-helper: trivial cleanup
  transport-helper: propagate recvline() error pushing
  remote-helpers: make recvline return an error
  transport-helper: remove barely used xchgline()

Merge branch 'db/make-with-curl'

Ask curl-config how to link with the curl library, instead of
having only a limited configurability knobs in the Makefile.

* db/make-with-curl:
  Makefile: allow static linking against libcurl
  Makefile: use curl-config to determine curl flags

mergetool: document the default for --[no-]prompt

The original motivation of using the prompt was to confirm to run a
tool on this particular (as opposed to another) path, but the user
can also take the prompt as to confirm to run this (as opposed to
some other) tool.  The latter of which of course is irritating for
those who told which exact tool to use, which is the reason why we
are flipping the default.

During the review discussion of the patch, many people (including
the maintainer) missed that a user can find the prompt useful way to
skip running the tool on particular paths.  Clarify it by adding a
brief half-sentence to the description.

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

git-remote-mediawiki: fix encoding issue for UTF-8 media files

When a media file contains valid UTF-8, git-remote-mediawiki tried to be
too clever about the encoding, and the call to utf8::downgrade() on the
downloaded content was failing with

  Wide character in subroutine entry at git-remote-mediawiki line 583.

Instead, use $response->decode() to apply decoding linked to the
Content-Encoding: header, and return the content without attempting any
charset decoding.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote-mediawiki: allow stop/start-ing the test server

Previously, the user had to launch a complete re-install after a lighttpd
stop (e.g. a reboot).

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9117: use --prefix "" instead of --prefix=""

Versions of Perl's Getopt::Long module before 2.37 do not contain
this fix that first appeared in Getopt::Long version 2.37:

* Bugfix: With gnu_compat, --foo= will no longer trigger "Option
  requires an argument" but return the empty string.

Instead of using --prefix="" use --prefix "" when testing an
explictly empty prefix string in order to work with older versions
of Perl's Getopt::Long module.

Also add a paragraph on this workaround to the documentation of
git-svn itself.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: windows drive prefix (e.g. C:) appears only at the beginning

Tighten the regexp used in the "file_name_is_absolute" replacement
used on msys to declare that only "[a-zA-Z]:" that appear at the
very beginning is a path with a drive-prefix.

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

blame: dynamic blame_date_width for different locales

When show date in relative date format for git-blame, the max display
width of datetime is set as the length of the string "Thu Oct 19
16:00:04 2006 -0700" (30 characters long).  But actually the max width
for C locale is only 22 (the length of string "x years, xx months ago").
And for other locale, it maybe smaller.  E.g. For Chinese locale, only
needs a half (16-character width).

Set blame_date_width as the display width of _("4 years, 11 months
ago"), so that translators can make the choice.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

blame: fix broken time_buf paddings in relative timestamp

Command `git blame --date relative` aligns the date field with a
fixed-width (defined by blame_date_width), and if time_str is shorter
than that, it adds spaces for padding.  But there are two bugs in the
following codes:

        time_len = strlen(time_str);
        ...
        memset(time_buf + time_len, ' ', blame_date_width - time_len);

 1. The type of blame_date_width is size_t, which is unsigned.  If
    time_len is greater than blame_date_width, the result of
    "blame_date_width - time_len" will never be a negative number, but a
    really big positive number, and will cause memory overwrite.

    This bug can be triggered if either l10n message for function
    show_date_relative() in date.c is longer than 30 characters, then
    `git blame --date relative` may exit abnormally.

 2. When show blame information with relative time, the UTF-8 characters
    in time_str will break the alignment of columns after the date field.
    This is because the time_buf padding with spaces should have a
    constant display width, not a fixed strlen size.  So we should call
    utf8_strwidth() instead of strlen() for width calibration.

Helped-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: zh_CN.po: translate 46 new messages (2229t0f0u)

Translations for git v2.0.0-rc0.  Also correct translatioins on relative
date in date.c with help from Brian Gesiak ($gmane/246390).

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

Merge branch 'fr-po' of git://github.com/jnavila/git

* 'fr-po' of git://github.com/jnavila/git:
  l10n: fr translation for v2.0.0rc0 (2228t)

ewah_bitmap.c: do not assume size_t and eword_t are the same size

When buffer_grow changes the size of the buffer using realloc,
it first computes and saves the rlw pointer's offset into the
buffer using (uint8_t *) math before the realloc but then
restores it using (eword_t *) math.

In order to do this it's necessary to convert the (uint8_t *)
offset into an (eword_t *) offset.  It was doing this by
dividing by the sizeof(size_t).  Unfortunately sizeof(size_t)
is not same as sizeof(eword_t) on all platforms.

This causes illegal memory accesses and other bad things to
happen when attempting to use bitmaps on those platforms.

Fix this by dividing by the sizeof(eword_t) instead which
will always be correct for all platforms.

Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge: enable defaulttoupstream by default

There's no point in this:

% git merge
fatal: No commit specified and merge.defaultToUpstream not set.

We know the most likely scenario is that the user wants to merge the
upstream, and if not, he can set merge.defaultToUpstream to false.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mergetool: run prompt only if guessed tool

It's annoying to see the prompt:

  Hit return to start merge resolution tool (foo):

Every time the user does 'git mergetool' even if the user already
configured 'foo' as the wanted tool.

Display this prompt only when the user hasn't explicitly configured a
tool.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mergetools: add vimdiff3 mode

It's similar to the default, except that the other windows are hidden.
This ensures that removed/added colors are still visible on the main
merge window, but the other windows not visible.

Specially useful with merge.conflictstyle=diff3.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Acked-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: fr translation for v2.0.0rc0 (2228t)

Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Matthieu Baerts <matttbe@gmail.com>
Signed-off-by: Xavier Mehrenberger <xavier.mehrenberger@gmail.com>