Merge branch 'sh/pull-rebase-preserve'

"git pull --rebase" always flattened the history; pull.rebase can
now be set to "preserve" to invoke "rebase --preserve-merges".

* sh/pull-rebase-preserve:
  pull: allow pull to preserve merges when rebasing

Merge branch 'nd/push-no-thin'

"git push --no-thin" was a no-op by mistake.

* nd/push-no-thin:
  push: respect --no-thin

Update draft release notes to 1.8.5 for the second batch of topics

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

Merge branch 'nd/magic-pathspec'

Use "struct pathspec" interface in more places, instead of array of
characters, the latter of which cannot express magic pathspecs
(e.g. ":(icase)makefile" that matches both Makefile and makefile).

* nd/magic-pathspec:
  add: lift the pathspec magic restriction on "add -p"
  pathspec: catch prepending :(prefix) on pathspec with short magic

Merge branch 'jk/mailmap-incomplete-line'

* jk/mailmap-incomplete-line:
  mailmap: handle mailmap blobs without trailing newlines

Merge branch 'sp/clip-read-write-to-8mb'

Send a large request to read(2)/write(2) as a smaller but still
reasonably large chunks, which would improve the latency when the
operation needs to be killed and incidentally works around broken
64-bit systems that cannot take a 2GB write or read in one go.

* sp/clip-read-write-to-8mb:
  Revert "compat/clipped-write.c: large write(2) fails on Mac OS X/XNU"
  xread, xwrite: limit size of IO to 8MB

Merge branch 'tg/index-struct-sizes'

The code that reads from a region that mmaps an on-disk index
assumed that "int"/"short" are always 32/16 bits.

* tg/index-struct-sizes:
  read-cache: use fixed width integer types

Merge branch 'jc/transport-do-not-use-connect-twice-in-fetch'

The auto-tag-following code in "git fetch" tries to reuse the same
transport twice when the serving end does not cooperate and does
not give tags that point to commits that are asked for as part of
the primary transfer.  Unfortunately, Git-aware transport helper
interface is not designed to be used more than once, hence this
does not work over smart-http transfer.

* jc/transport-do-not-use-connect-twice-in-fetch:
  builtin/fetch.c: Fix a sparse warning
  fetch: work around "transport-take-over" hack
  fetch: refactor code that fetches leftover tags
  fetch: refactor code that prepares a transport
  fetch: rename file-scope global "transport" to "gtransport"
  t5802: add test for connect helper

Merge branch 'es/contacts-blame-L-multi'

* es/contacts-blame-L-multi:
  contacts: reduce git-blame invocations
  contacts: gather all blame sources prior to invoking git-blame
  contacts: validate hunk length earlier

Merge branch 'jc/url-match'

Allow section.<urlpattern>.var configuration variables to be
treated as a "virtual" section.var given a URL, and use the
mechanism to enhance http.* configuration variables.

This is a reroll of Kyle J. McKay's work.

* jc/url-match:
  builtin/config.c: compilation fix
  config: "git config --get-urlmatch" parses section.<url>.key
  builtin/config: refactor collect_config()
  config: parse http.<url>.<variable> using urlmatch
  config: add generic callback wrapper to parse section.<url>.key
  config: add helper to normalize and match URLs
  http.c: fix parsing of http.sslCertPasswordProtected variable

Merge branch 'jl/submodule-mv'

"git mv A B" when moving a submodule A does "the right thing",
inclusing relocating its working tree and adjusting the paths in
the .gitmodules file.

* jl/submodule-mv: (53 commits)
  rm: delete .gitmodules entry of submodules removed from the work tree
  mv: update the path entry in .gitmodules for moved submodules
  submodule.c: add .gitmodules staging helper functions
  mv: move submodules using a gitfile
  mv: move submodules together with their work trees
  rm: do not set a variable twice without intermediate reading.
  t6131 - skip tests if on case-insensitive file system
  parse_pathspec: accept :(icase)path syntax
  pathspec: support :(glob) syntax
  pathspec: make --literal-pathspecs disable pathspec magic
  pathspec: support :(literal) syntax for noglob pathspec
  kill limit_pathspec_to_literal() as it's only used by parse_pathspec()
  parse_pathspec: preserve prefix length via PATHSPEC_PREFIX_ORIGIN
  parse_pathspec: make sure the prefix part is wildcard-free
  rename field "raw" to "_raw" in struct pathspec
  tree-diff: remove the use of pathspec's raw[] in follow-rename codepath
  remove match_pathspec() in favor of match_pathspec_depth()
  remove init_pathspec() in favor of parse_pathspec()
  remove diff_tree_{setup,release}_paths
  convert common_prefix() to use struct pathspec
  ...

Merge branch 'es/blame-L-twice'

Teaches "git blame" to take more than one -L ranges.

* es/blame-L-twice:
  line-range: reject -L line numbers less than 1
  t8001/t8002: blame: add tests of -L line numbers less than 1
  line-range: teach -L^:RE to search from start of file
  line-range: teach -L:RE to search from end of previous -L range
  line-range: teach -L^/RE/ to search from start of file
  line-range-format.txt: document -L/RE/ relative search
  log: teach -L/RE/ to search from end of previous -L range
  blame: teach -L/RE/ to search from end of previous -L range
  line-range: teach -L/RE/ to search relative to anchor point
  blame: document multiple -L support
  t8001/t8002: blame: add tests of multiple -L options
  blame: accept multiple -L ranges
  blame: inline one-line function into its lone caller
  range-set: publish API for re-use by git-blame -L
  line-range-format.txt: clarify -L:regex usage form
  git-log.txt: place each -L option variation on its own line

Merge branch 'tr/log-full-diff-keep-true-parents'

Output from "git log --full-diff -- <pathspec>" looked strange,
because comparison was done with the previous ancestor that touched
the specified <pathspec>, causing the patches for paths outside the
pathspec to show more than the single commit has changed.

Tweak "git reflog -p" for the same reason using the same mechanism.

* tr/log-full-diff-keep-true-parents:
  log: use true parents for diff when walking reflogs
  log: use true parents for diff even when rewriting

Merge branch 'jk/cat-file-batch-optim'

Rework the reverted change to `cat-file --batch-check`.

* jk/cat-file-batch-optim:
  cat-file: only split on whitespace when %(rest) is used

Merge branch 'es/blame-L-more'

More fixes to the code to parse the "-L" option in "log" and "blame".

* es/blame-L-more:
  blame: reject empty ranges -L,+0 and -L,-0
  t8001/t8002: blame: demonstrate acceptance of bogus -L,+0 and -L,-0
  blame: reject empty ranges -LX,+0 and -LX,-0
  t8001/t8002: blame: demonstrate acceptance of bogus -LX,+0 and -LX,-0
  log: fix -L bounds checking bug
  t4211: retire soon-to-be unimplementable tests
  t4211: log: demonstrate -L bounds checking bug
  blame: fix -L bounds checking bug
  t8001/t8002: blame: add empty file & partial-line tests
  t8001/t8002: blame: demonstrate -L bounds checking bug
  t8001/t8002: blame: decompose overly-large test

Merge branch 'db/http-savecookies'

* db/http-savecookies:
  t5551: Remove header from curl cookie file
  http: add http.savecookies option to write out HTTP cookies

Merge branch 'jc/push-cas'

Allow a safer "rewind of the remote tip" push than blind "--force",
by requiring that the overwritten remote ref to be unchanged since
the new history to replace it was prepared.

The machinery is more or less ready.  The "--force" option is again
the big red button to override any safety, thanks to J6t's sanity
(the original round allowed --lockref to defeat --force).

The logic to choose the default implemented here is fragile
(e.g. "git fetch" after seeing a failure will update the
remote-tracking branch and will make the next "push" pass,
defeating the safety pretty easily).  It is suitable only for the
simplest workflows, and it may hurt users more than it helps them.

* jc/push-cas:
  push: teach --force-with-lease to smart-http transport
  send-pack: fix parsing of --force-with-lease option
  t5540/5541: smart-http does not support "--force-with-lease"
  t5533: test "push --force-with-lease"
  push --force-with-lease: tie it all together
  push --force-with-lease: implement logic to populate old_sha1_expect[]
  remote.c: add command line option parser for "--force-with-lease"
  builtin/push.c: use OPT_BOOL, not OPT_BOOLEAN
  cache.h: move remote/connect API out of it

Merge branch 'nd/clone-connectivity-shortcut'

* nd/clone-connectivity-shortcut:
  smart http: use the same connectivity check on cloning

Merge branch 'jc/diff-filter-negation'

Teach "git diff --diff-filter" to express "I do not want to see
these classes of changes" more directly by listing only the
unwanted ones in lowercase (e.g. "--diff-filter=d" will show
everything but deletion) and deprecate "diff-files -q" which did
the same thing as "--diff-filter=d".

* jc/diff-filter-negation:
  diff: deprecate -q option to diff-files
  diff: allow lowercase letter to specify what change class to exclude
  diff: reject unknown change class given to --diff-filter
  diff: preparse --diff-filter string argument
  diff: factor out match_filter()
  diff: pass the whole diff_options to diffcore_apply_filter()

Merge branch 'ms/fetch-prune-configuration'

Allow fetch.prune and remote.*.prune configuration variables to be set,
and "git fetch" to behave as if "--prune" is given.

"git fetch" that honors remote.*.prune is fine, but I wonder if we
should somehow make "git push" aware of it as well.  Perhaps
remote.*.prune should not be just a boolean, but a 4-way "none",
"push", "fetch", "both"?

* ms/fetch-prune-configuration:
  fetch: make --prune configurable

remote-bzr: reuse bzrlib transports when possible

Pass a list of open bzrlib.transport.Transport objects to each bzrlib
function that might create a transport.  This enables bzrlib to reuse
existing transports when possible, avoiding multiple concurrent
connections to the same remote server.

If the remote server is accessed via ssh, this fixes a couple of
problems:
  * If the user does not have keys loaded into an ssh agent, the user
    may be prompted for a password multiple times.
  * If the user is using OpenSSH and the ControlMaster setting is set
    to auto, git-remote-bzr might hang.  This is because bzrlib closes
    the multiple ssh sessions in an undefined order and might try to
    close the master ssh session before the other sessions.  The
    master ssh process will not exit until the other sessions have
    exited, causing a deadlock.  (The ssh sessions are closed in an
    undefined order because bzrlib relies on the Python garbage
    collector to trigger ssh session termination.)

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

Sync with maint

* maint:
  Documentation/git-merge.txt: fix formatting of example block

Merge branch 'nd/fetch-pack-shallow-fix' into maint

The recent "short-cut clone connectivity check" topic broke a shallow
repository when a fetch operation tries to auto-follow tags.

* nd/fetch-pack-shallow-fix:
  fetch-pack: do not remove .git/shallow file when --depth is not specified

Merge branch 'hv/config-from-blob' into maint

Compilation fix on platforms with fgetc() and friends defined as
macros.

* hv/config-from-blob:
  config: do not use C function names as struct members

Merge branch 'maint-1.8.3' into maint

* maint-1.8.3:
  Documentation/git-merge.txt: fix formatting of example block

Merge branch 'maint-1.8.2' into maint-1.8.3

* maint-1.8.2:
  Documentation/git-merge.txt: fix formatting of example block

add: lift the pathspec magic restriction on "add -p"

Since 480ca64 (convert run_add_interactive to use struct pathspec -
2013-07-14), we have unconditionally passed :(prefix)xxx to
add-interactive.perl. It implies that all commands
add-interactive.perl calls must be aware of pathspec magic, or
:(prefix) is barfed. The restriction to :/ only becomes unnecessary.

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

pathspec: catch prepending :(prefix) on pathspec with short magic

:(prefix) is in the long form. Suppose people pass :!foo with '!'
being the short form of magic 'bar', the code will happily turn it to
:(prefix..)!foo, which makes '!' part of the path and no longer a magic.

The correct form must be ':(prefix..,bar)foo', but as so far we
haven't had any magic in short form yet (*), the code to convert from
short form to long one will be inactive anyway. Let's postpone it
until a real short form magic appears.

(*) The short form magic '/' is a special case and won't be caught by
this die(), which is correct. When '/' magic is detected, prefixlen is
set back to 0 and the whole "if (prefixlen..)" block is skipped.

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

Documentation/git-merge.txt: fix formatting of example block

You need at least four dashes in a line to have it recognized as listing
block delimiter by asciidoc.

Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pull: allow pull to preserve merges when rebasing

If a user is working on master, and has merged in their feature branch, but now
has to "git pull" because master moved, with pull.rebase their feature branch
will be flattened into master.

This is because "git pull" currently does not know about rebase's preserve
merges flag, which would avoid this behavior, as it would instead replay just
the merge commit of the feature branch onto the new master, and not replay each
individual commit in the feature branch.

Add a --rebase=preserve option, which will pass along --preserve-merges to
rebase.

Also add 'preserve' to the allowed values for the pull.rebase config setting.

Signed-off-by: Stephen Haberman <stephen@exigencecorp.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update draft release notes after merging the first batch of topics

Merge branch 'sb/parseopt-boolean-removal'

Convert most uses of OPT_BOOLEAN/OPTION_BOOLEAN that can use
OPT_BOOL/OPTION_BOOLEAN which have much saner semantics, and turn
remaining ones into OPT_SET_INT, OPT_COUNTUP, etc. as necessary.

* sb/parseopt-boolean-removal:
  revert: use the OPT_CMDMODE for parsing, reducing code
  checkout-index: fix negations of even numbers of -n
  config parsing options: allow one flag multiple times
  hash-object: replace stdin parsing OPT_BOOLEAN by OPT_COUNTUP
  branch, commit, name-rev: ease up boolean conditions
  checkout: remove superfluous local variable
  log, format-patch: parsing uses OPT__QUIET
  Replace deprecated OPT_BOOLEAN by OPT_BOOL
  Remove deprecated OPTION_BOOLEAN for parsing arguments

Merge branch 'jc/parseopt-command-modes'

Many commands use --dashed-option as a operation mode selector
(e.g. "git tag --delete") that the user can use at most one
(e.g. "git tag --delete --verify" is a nonsense) and you cannot
negate (e.g. "git tag --no-delete" is a nonsense).  Make it easier
for users of parse_options() to enforce these restrictions.

* jc/parseopt-command-modes:
  tag: use OPT_CMDMODE
  parse-options: add OPT_CMDMODE()

Merge branch 'jl/some-submodule-config-are-not-boolean'

* jl/some-submodule-config-are-not-boolean:
  avoid segfault on submodule.*.path set to an empty "true"

Merge branch 'sg/bash-prompt-lf-in-cwd-test'

* sg/bash-prompt-lf-in-cwd-test:
  bash prompt: test the prompt with newline in repository path

Merge branch 'sb/diff-delta-remove-needless-comparison'

* sb/diff-delta-remove-needless-comparison:
  create_delta_index: simplify condition always evaluating to true

Merge branch 'fc/unpack-trees-leakfix'

* fc/unpack-trees-leakfix:
  unpack-trees: plug a memory leak

Merge branch 'aj/p4-symlink-lose-nl'

* aj/p4-symlink-lose-nl:
  git-p4: Fix occasional truncation of symlink contents.

Merge branch 'fc/remote-hg-shared-setup'

* fc/remote-hg-shared-setup:
  remote-hg: add shared repo upgrade
  remote-hg: ensure shared repo is initialized

Merge branch 'sb/misc-cleanup'

* sb/misc-cleanup:
  rm: remove unneeded null pointer check
  diff: fix a possible null pointer dereference
  diff: remove ternary operator evaluating always to true

Merge branch 'nd/gc-lock-against-each-other'

* nd/gc-lock-against-each-other:
  gc: reject if another gc is running, unless --force is given

Merge branch 'ap/remote-hg-tilde-is-home-directory'

* ap/remote-hg-tilde-is-home-directory:
  remote-hg: fix path when cloning with tilde expansion

Merge branch 'mm/no-shell-escape-in-die-message'

Fixes a minor bug in "git rebase -i" (there could be others, as the
root cause is pretty generic) where the code feeds a random, data
dependeant string to 'echo' and expects it to come out literally.

* mm/no-shell-escape-in-die-message:
  die_with_status: use "printf '%s\n'", not "echo"

Merge branch 'tr/fd-gotcha-fixes'

Finishing touches to an earlier fix already in 'master'.

* tr/fd-gotcha-fixes:
  t0070: test that git_mkstemps correctly checks return value of open()

Merge branch 'bc/unuse-packfile'

Handle memory pressure and file descriptor pressure separately when
deciding to release pack windows to honor resource limits.

* bc/unuse-packfile:
  Don't close pack fd when free'ing pack windows
  sha1_file: introduce close_one_pack() to close packs on fd pressure

Merge branch 'da/darwin'

* da/darwin:
  OS X: Fix redeclaration of die warning
  Makefile: Fix APPLE_COMMON_CRYPTO with BLK_SHA1
  imap-send: use Apple's Security framework for base64 encoding

Merge branch 'nd/sq-quote-buf'

Code simplification as a preparatory step to something larger.

* nd/sq-quote-buf:
  quote: remove sq_quote_print()
  tar-tree: remove dependency on sq_quote_print()
  for-each-ref, quote: convert *_quote_print -> *_quote_buf

Merge branch 'rr/feed-real-path-to-editor'

* rr/feed-real-path-to-editor:
  editor: use canonicalized absolute path

Merge branch 'jk/fast-import-empty-ls'

* jk/fast-import-empty-ls:
  fast-import: allow moving the root tree
  fast-import: allow ls or filecopy of the root tree
  fast-import: set valid mode on root tree in "ls"
  t9300: document fast-import empty path issues

Merge branch 'km/svn-1.8-serf-only'

Subversion 1.8.0 that was recently released breaks older subversion
clients coming over http/https in various ways.

* km/svn-1.8-serf-only:
  Git.pm: revert _temp_cache use of temp_is_locked
  git-svn: allow git-svn fetching to work using serf
  Git.pm: add new temp_is_locked function

Merge branch 'jc/check-x-z'

"git check-ignore -z" applied the NUL termination to both its input
(with --stdin) and its output, but "git check-attr -z" ignored the
option on the output side.

This is potentially a backward incompatible fix.  Let's see if
anybody screams before deciding if we want to do anything to help
existing users (there may be none).

* jc/check-x-z:
  check-attr -z: a single -z should apply to both input and output
  check-ignore -z: a single -z should apply to both input and output
  check-attr: the name of the character is NUL, not NULL
  check-ignore: the name of the character is NUL, not NULL

Merge branch 'maint'

* maint:
  fix shell syntax error in template
  l10n: fr.po: hotfix for commit 6b388fc

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

* git://github.com/git-l10n/git-po:
  l10n: fr.po: hotfix for commit 6b388fc

Merge branch 'maint-1.8.3' into maint

* maint-1.8.3:
  fix shell syntax error in template

Merge branch 'maint-1.8.2' into maint-1.8.3

* maint-1.8.2:
  fix shell syntax error in template

Start the post-1.8.4 cycle

It is tentatively called 1.8.5, but it should be an easy matter of
renaming the release-notes file and RelNotes symlink to later call
it 1.9 near the end of the cycle if we wanted to.

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

Merge branch 'bc/completion-for-bash-3.0'

Some people still use rather old versions of bash, which cannot
grok some constructs like 'printf -v varname' the prompt and
completion code started to use recently.

* bc/completion-for-bash-3.0:
  contrib/git-prompt.sh: handle missing 'printf -v' more gracefully
  t9902-completion.sh: old Bash still does not support array+=('') notation
  git-completion.bash: use correct Bash/Zsh array length syntax

Merge branch 'sp/doc-smart-http'

* sp/doc-smart-http:
  Document the HTTP transport protocols

Merge branch 'mm/war-on-whatchanged'

* mm/war-on-whatchanged:
  whatchanged: document its historical nature
  core-tutorial: trim the section on Inspecting Changes

Merge branch 'rt/doc-merge-file-diff3'

* rt/doc-merge-file-diff3:
  Documentation/git-merge-file: document option "--diff3"

Merge branch 'mb/docs-favor-en-us'

Declare that the official grammar & spelling of the source of this
project is en_US, but strongly discourage patches only to "fix"
existing en_UK strings to avoid unnecessary churns.

* mb/docs-favor-en-us:
  Provide some linguistic guidance for the documentation.

Merge branch 'rj/doc-rev-parse'

* rj/doc-rev-parse:
  rev-parse(1): logically group options
  rev-parse: remove restrictions on some options

Merge branch 'hv/config-from-blob'

Portability fix.

* hv/config-from-blob:
  config: do not use C function names as struct members

Merge branch 'nd/fetch-pack-shallow-fix'

The recent "short-cut clone connectivity check" topic broke a
shallow repository when a fetch operation tries to auto-follow tags.

* nd/fetch-pack-shallow-fix:
  fetch-pack: do not remove .git/shallow file when --depth is not specified

fix shell syntax error in template

An if clause must not be empty; add a "colon" command.

Signed-off-by: Thorsten Glaser <t.glaser@tarent.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: fr.po: hotfix for commit 6b388fc

Fix many typos and add some new translations (1277/2080 messages
translated).

Closes git-l10n/git-po/pull/63.

Signed-off-by: Sebastien Helleu <flashcode@flashtux.org>
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

builtin/fetch.c: Fix a sparse warning

Sparse issues an "'prepare_transport' was not declared. Should it
be static?" warning. In order to suppress the warning, since this
symbol only requires file scope, we simply add the static modifier
to it's declaration.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mailmap: handle mailmap blobs without trailing newlines

The read_mailmap_buf function reads each line of the mailmap
using strchrnul, like:

    const char *end = strchrnul(buf, '\n');
    unsigned long linelen = end - buf + 1;

But that's off-by-one when we actually hit the NUL byte; our
line does not have a terminator, and so is only "end - buf"
bytes long. As a result, when we subtract the linelen from
the total len, we end up with (unsigned long)-1 bytes left
in the buffer, and we start reading random junk from memory.

We could fix it with:

    unsigned long linelen = end - buf + !!*end;

but let's take a step back for a moment. It's questionable
in the first place for a function that takes a buffer and
length to be using strchrnul. But it works because we only
have one caller (and are only likely to ever have this one),
which is handing us data from read_sha1_file. Which means
that it's always NUL-terminated.

Instead of tightening the assumptions to make the
buffer/length pair work for a caller that doesn't actually
exist, let's let loosen the assumptions to what the real
caller has: a modifiable, NUL-terminated string.

This makes the code simpler and shorter (because we don't
have to correlate strchrnul with the length calculation),
correct (because the code with the off-by-one just goes
away), and more efficient (we can drop the extra allocation
we needed to create NUL-terminated strings for each line,
and just terminate in place).

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

config: do not use C function names as struct members

According to C99, section 7.1.4:

  Any function declared in a header may be additionally
  implemented as a function-like macro defined in the
  header.

Therefore calling our struct member function pointer "fgetc"
may run afoul of unwanted macro expansion when we call:

  char c = cf->fgetc(cf);

This turned out to be a problem on uclibc, which defines
fgetc as a macro and causes compilation failure.

The standard suggests fixing this in a few ways:

  1. Using extra parentheses to inhibit the function-like
     macro expansion. E.g., "(cf->fgetc)(cf)". This is
     undesirable as it's ugly, and each call site needs to
     remember to use it (and on systems without the macro,
     forgetting will compile just fine).

  2. Using #undef (because a conforming implementation must
     also be providing fgetc as a function). This is
     undesirable because presumably the implementation was
     using the macro for a performance benefit, and we are
     dropping that optimization.

Instead, we can simply use non-colliding names.

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

fetch-pack: do not remove .git/shallow file when --depth is not specified

fetch_pack() can remove .git/shallow file when a shallow repository
becomes a full one again. This behavior is triggered incorrectly when
tags are also fetched because fetch_pack() will be called twice. At
the first fetch_pack() call:

 - shallow_lock is set up
 - alternate_shallow_file points to shallow_lock.filename, which is
   "shallow.lock"
 - commit_lock_file is called, which sets shallow_lock.filename to "".
   alternate_shallow_file also becomes "" because it points to the
   same memory.

At the second call, setup_alternate_shallow() is not called and
alternate_shallow_file remains "". It's mistaken as unshallow case and
.git/shallow is removed. The end result is a broken repository.

Fix this by always initializing alternate_shallow_file when
fetch_pack() is called. As an extra measure, check if args->depth > 0
before commit/rollback shallow file.

Reported-by: Kacper Kornet <kornet@camk.edu.pl>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.8.4

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

contrib/git-prompt.sh: handle missing 'printf -v' more gracefully

Old Bash (3.0) which is distributed with RHEL 4.X and other ancient
platforms that are still in wide use, do not have a printf that
supports -v.  Neither does Zsh (which is already handled in the code).

As suggested by Junio, let's test whether printf supports the -v
option and store the result.  Then later, we can use it to
determine whether 'printf -v' can be used, or whether printf
must be called in a subshell.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9902-completion.sh: old Bash still does not support array+=('') notation

Old Bash (3.0) which is distributed with RHEL 4.X and other ancient
platforms that are still in wide use, does not understand the
array+=() notation.  Let's use an explicit assignment to the new array
element which works everywhere, like:

   array[${#array[@]}+1]=''

The right-hand side '' is not strictly necessary, but in this case
I think it is more clear.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-completion.bash: use correct Bash/Zsh array length syntax

The syntax for retrieving the number of elements in an array is:

   ${#name[@]}

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Typofix draft release notes to 1.8.4

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

Document the HTTP transport protocols

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Revised-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

read-cache: use fixed width integer types

Use the fixed width integer types uint16_t and uint32_t for on-disk
structures; unsigned short and unsigned int do not have a guaranteed
size.

Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Revert "compat/clipped-write.c: large write(2) fails on Mac OS X/XNU"

This reverts commit 6c642a878688adf46b226903858b53e2d31ac5c3.

The previous commit introduced a size limit on IO chunks on all
platforms.  The compat clipped_write() is not needed anymore.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

xread, xwrite: limit size of IO to 8MB

Checking out 2GB or more through an external filter (see test) fails
on Mac OS X 10.8.4 (12E55) for a 64-bit executable with:

    error: read from external filter cat failed
    error: cannot feed the input to external filter cat
    error: cat died of signal 13
    error: external filter cat failed 141
    error: external filter cat failed

The reason is that read() immediately returns with EINVAL when asked
to read more than 2GB.  According to POSIX [1], if the value of
nbyte passed to read() is greater than SSIZE_MAX, the result is
implementation-defined.  The write function has the same restriction
[2].  Since OS X still supports running 32-bit executables, the
32-bit limit (SSIZE_MAX = INT_MAX = 2GB - 1) seems to be also
imposed on 64-bit executables under certain conditions.  For write,
the problem has been addressed earlier [6c642a].

Address the problem for read() and write() differently, by limiting
size of IO chunks unconditionally on all platforms in xread() and
xwrite().  Large chunks only cause problems, like causing latencies
when killing the process, even if OS X was not buggy.  Doing IO in
reasonably sized smaller chunks should have no negative impact on
performance.

The compat wrapper clipped_write() introduced earlier [6c642a] is
not needed anymore.  It will be reverted in a separate commit.  The
new test catches read and write problems.

Note that 'git add' exits with 0 even if it prints filtering errors
to stderr.  The test, therefore, checks stderr.  'git add' should
probably be changed (sometime in another commit) to exit with
nonzero if filtering fails.  The test could then be changed to use
test_must_fail.

Thanks to the following people for suggestions and testing:

    Johannes Sixt <j6t@kdbg.org>
    John Keeping <john@keeping.me.uk>
    Jonathan Nieder <jrnieder@gmail.com>
    Kyle J. McKay <mackyle@gmail.com>
    Linus Torvalds <torvalds@linux-foundation.org>
    Torsten Bögershausen <tboegi@web.de>

[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html
[2] http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html

[6c642a] commit 6c642a878688adf46b226903858b53e2d31ac5c3
    compate/clipped-write.c: large write(2) fails on Mac OS X/XNU

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

avoid segfault on submodule.*.path set to an empty "true"

Git fails due to a segmentation fault if a submodule path is empty.
Here is an example .gitmodules that will cause a segmentation fault:

    [submodule "foo-module"]
      path
      url = http://host/repo.git
    $ git status
    Segmentation fault (core dumped)

This is because the parsing of "submodule.*.path" is not prepared to
see a value-less "true" and assumes that the value is always
non-NULL (parsing of "ignore" has the same problem).

Fix it by checking the NULL-ness of value and complain with
config_error_nonbool().

Signed-off-by: Jharrod LaFon <jlafon@eyesopen.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.8.4-rc4

As we had to revert two topics at the last minute, let's have
another (hopefully short) round of rc to make sure the final release
will be sound.

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

bash prompt: test the prompt with newline in repository path

Newlines in the path to a git repository were not an issue for the
git-specific bash prompt before commit efaa0c1532 (bash prompt:
combine 'git rev-parse' executions in the main code path, 2013-06-17),
because the path returned by 'git rev-parse --git-dir' was directly
stored in a variable, and this variable was later always accessed
inside double quotes.

Newlines are not an issue after commit efaa0c1532 either, but it's
more subtle.  Since efaa0c1532 we use the following single 'git
rev-parse' execution to query various info about the repository:

  git rev-parse --git-dir --is-inside-git-dir \
          --is-bare-repository --is-inside-work-tree

The results to these queries are separated by a newline character in
the output, e.g.:

  /home/szeder/src/git/.git
  false
  false
  true

A newline in the path to the git repository could potentially break
the parsing of these results and ultimately the bash prompt, unless
the parsing is done right.  Commit efaa0c1532 got it right, as I
consciously started parsing 'git rev-parse's output from the end,
where each record is a single line containing either 'true' or 'false'
or, after e3e0b9378b (bash prompt: combine 'git rev-parse' for
detached head, 2013-06-24), the abbreviated commit object name, and
all what remains at the beginning is the path to the git repository,
no matter how many lines it is.

This subtlety really warrants its own test, especially since I didn't
explain it in the log message or in an in-code comment back then, so
add a test to excercise the prompt with newline characters in the path
to the repository.  Guard this test with the FUNNYNAMES prerequisite,
because not all filesystems support newlines in filenames.  Note that
'git rev-parse --git-dir' prints '.git' or '.' when at the top of the
worktree or the repository, respectively, and only prints the full
path to the repository when in a subdirectory, hence the need for
changing into a subdir in the test.

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

create_delta_index: simplify condition always evaluating to true

The code sequence  ' (1u << i) < hsize && i < 31 ' is a multi step
process, whose first step requires that 'i' is already less that 31,
otherwise the result (1u << i)  is undefined (and  'undef_val < hsize'
can therefore be assumed to be 'false'), and so the later test  i < 31
can always be optimized away as dead code ('i' is already less than 31,
or the short circuit 'and' applies).

So we need to get rid of that code. One way would be to exchange the
order of the conditions, so the expression 'i < 31 && (1u << i) < hsize'
would remove that optimized unstable code already.

However when checking the previous lines in that function, we can deduce
that 'hsize' must always be smaller than (1u<<31), since 506049c7df2c6
(fix >4GiB source delta assertion failure), because 'entries' is
capped at an upper bound of 0xfffffffeU, so 'hsize' contains a maximum
value of 0x3fffffff, which is smaller than (1u<<31), so the value of
'i' will never be larger than 31 and we can remove that condition
entirely.

Signed-off-by: Stefan Beller <stefanbeller@googlemail.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Acked-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Revert "Add new @ shortcut for HEAD"

This reverts commit cdfd94837b27c220f70f032b596ea993d195488f, as it
does not just apply to "@" (and forms with modifiers like @{u}
applied to it), but also affects e.g. "refs/heads/@/foo", which it
shouldn't.

The basic idea of giving a short-hand might be good, and the topic
can be retried later, but let's revert to avoid affecting existing
use cases for now for the upcoming release.

Revert "git stash: avoid data loss when "git stash save" kills a directory"

This reverts commit a73653130edd6a8977106d45a8092c09040f9132, as it
has been reported that "ls-files --killed" is too time-consuming in
a deep directory with too many untracked crufts (e.g. $HOME/.git
tracking only a few files).

We'd need to revisit it later but "ls-files --killed" needs to be
optimized before it happens.

unpack-trees: plug a memory leak

Before overwriting the destination index, first let's discard its
contents.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Tested-by: Лежанкин Иван <abyss.7@gmail.com> wrote:
Reviewed-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 1.8.4-rc3

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: Add reference for french translation team
  l10n: fr.po: 821/2112 messages translated

Merge branch 'sb/mailmap-updates'

* sb/mailmap-updates:
  .mailmap: Combine more (name, email) to individual persons
  .mailmap: update long-lost friends with multiple defunct addresses

.mailmap: Combine more (name, email) to individual persons

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

.mailmap: update long-lost friends with multiple defunct addresses

A handful of past contributors are recorded with multiple e-mail
addresses, all of which are undeliverable.  With a lot of help from
Jonathan, we located all of them except for one person, and a pair
of addresses we suspect belong to a single person but we are not
certain.

Update the found ones with their currently preferred address, and
use the last known address to consolidate contributions by the lost
one.

Helped-by: Stefan Beller <stefanbeller@googlemail.com>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: respect --no-thin

- From the beginning of push.c in 755225d, 2006-04-29, "thin" option
  was enabled by default but could be turned off with --no-thin.

- Then Shawn changed the default to 0 in favor of saving server
  resources in a4503a1, 2007-09-09. --no-thin worked great.

- One day later, in 9b28851 Daniel extracted some code from push.c to
  create transport.c. He (probably accidentally) flipped the default
  value from 0 to 1 in transport_get().

From then on --no-thin is effectively no-op because git-push still
expects the default value to be false and only calls
transport_set_option() when "thin" variable in push.c is true (which
is unnecessary). Correct the code to respect --no-thin by calling
transport_set_option() in both cases.

receive-pack learns about --reject-thin-pack-for-testing option,
which only is for testing purposes, hence no document update.

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

git-remote-mediawiki: ignore generated git-mw

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

contacts: reduce git-blame invocations

git-contacts invokes git-blame once for each patch hunk it encounters.
No attempt is made to consolidate invocations for multiple hunks
referencing the same file at the same revision. This can become
expensive quickly.

Reduce the number of git-blame invocations by taking advantage of the
ability to specify multiple -L ranges for a single invocation.

Without this patch, on a randomly chosen range of commits:

  % time git-contacts 25fba78d36be6297^..23c339c0f262aad2 >/dev/null
  real  0m6.142s
  user  0m5.429s
  sys   0m0.356s

With this patch:

  % time git-contacts 25fba78d36be6297^..23c339c0f262aad2 >/dev/null
  real  0m2.285s
  user  0m2.093s
  sys   0m0.165s

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

contacts: gather all blame sources prior to invoking git-blame

git-contacts invokes git-blame immediately upon encountering a patch
hunk. No attempt is made to consolidate invocations for multiple hunks
referencing the same file at the same revision. This can become
expensive quickly.

Any effort to reduce the number of times git-blame is run will need to
to know in advance which line ranges to blame per file per revision.
Make this information available by collecting all sources as a distinct
step from invoking git-blame.  A subsequent patch will utilize the
information to optimize git-blame invocations.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

contacts: validate hunk length earlier

Rather than calling get_blame() with a zero-length hunk only to have it
rejected immediately, perform hunk-length validation earlier in order to
avoid calling get_blame() unnecessarily.

This is a preparatory step to simplify later patches which reduce the
number of git-blame invocations by collecting together all lines to
blame within a single file at a particular revision. By validating the
blame range early, the subsequent patch can more easily avoid adding
empty ranges at collection time.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

whatchanged: document its historical nature

Encourage new users to use 'log' instead.  These days, these
commands are unified and just have different defaults.

'git log' only allowed you to view the log messages and no diffs
when it was added in early June 2005.  It was only in early April
2006 that the command learned to take diff options.  Because of
this, power users tended to use 'whatchanged' that already existed
since mid May 2005 and supported diff options.

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

core-tutorial: trim the section on Inspecting Changes

Back when the core tutorial was written, `log` and `whatchanged`
were scripted Porcelains.  In the "Inspecting Changes" section that
talks about the plumbing commands in the diff family, it made sense
to use `log` and `whatchanged` as good examples of the use of these
plumbing commands, and because even these scripted Porcelains were
novelty (there wasn't the new end-user tutorial written), it made
some sense to illustrate uses of the `git log` (and `git
whatchanged`) scripted Porcelain commands.

But we no longer have scripted `log` and `whatchanged` to serve as
examples, and this document is not where the end users learn what
`git log` command is about.  Stop at briefly mentioning the
possibility of combining rev-list with diff-tree to build your own
log, and leave the end-user documentation of `log` to the new
tutorial and the user manual.

Also resurrect the last version of `git-log`, `git-whatchanged`, and
`git-show` to serve as examples to contrib/examples/ directory.

While at it, remove 'whatchanged' from a list of sample commands
that are affected by GIT_FLUSH environment variable. This is not
meant to be an exhaustive list but as a list of typical ones, and an
old command that is kept primarily for backward compatibility does
not belong to it.

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

git-p4: Fix occasional truncation of symlink contents.

Symlink contents in p4 print sometimes have a trailing
new line character, but sometimes it doesn't. git-p4
should only remove the last character if that character
is '\n'.

Signed-off-by: Alex Juncu <ajuncu@ixiacom.com>
Signed-off-by: Alex Badea <abadea@ixiacom.com>
Acked-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

remote-hg: add shared repo upgrade

If we have an old organization (v1.8.3), and want to upgrade to a newer
one (v1.8.4), the user would have to fetch the whole repository, instead
we can just move the repository, so the user would not notice any
difference.

Also, remove other clones, so in time they get set up as shared.

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