rebase-i-exec: Allow space in SHELL_PATH

On Windows, when Git is installed under "C:\Program Files\Git",
SHELL_PATH will include a space. Fix "git rebase --interactive --exec"
so that it works with spaces in SHELL_PATH.

Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>

Documentation: make environment variable formatting more consistent

Documentation/git.txt is not consistent in the way it
stylizes mentions of Environment Variables. Most of them are
enclosed in single quotes, some are enclosed in backticks,
some are not enclosed.

Signed-off-by: Andrey Rybak <rybak.a.v@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>

configure.ac: use $LIBS not $CFLAGS when testing -lpthread

Some linkers, namely the one on IRIX are rather strict concerning
the order or arguments for symbol resolution, i.e. no libraries
listed before objects or other libraries on the command line are
considered for symbol resolution.  Therefore, -lpthread can't work
if it's put in CFLAGS, because it will not be considered for
resolving pthread_key_create in conftest.o. Use $LIBS instead.

Signed-off-by: Rainer Canavan <git@canavan.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.6.3

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

Merge branch 'rs/daemon-plug-child-leak' into maint

"git daemon" uses "run_command()" without "finish_command()", so it
needs to release resources itself, which it forgot to do.

* rs/daemon-plug-child-leak:
  daemon: plug memory leak
  run-command: factor out child_process_clear()

Merge branch 'rs/wt-status-detached-branch-fix' into maint

"git status --branch --short" accessed beyond the constant string
"HEAD", which has been corrected.

* rs/wt-status-detached-branch-fix:
  wt-status: use skip_prefix() to get rid of magic string length constants
  wt-status: don't skip a magical number of characters blindly
  wt-status: avoid building bogus branch name with detached HEAD
  wt-status: exit early using goto in wt_shortstatus_print_tracking()
  t7060: add test for status --branch on a detached HEAD

Merge branch 'jk/initialization-fix-to-add-submodule-odb' into maint

We peek objects from submodule's object store by linking it to the
list of alternate object databases, but the code to do so forgot to
correctly initialize the list.

* jk/initialization-fix-to-add-submodule-odb:
  add_submodule_odb: initialize alt_odb list earlier

Merge branch 'js/misc-fixes' into maint

Various compilation fixes and squelching of warnings.

* js/misc-fixes:
  Correct fscanf formatting string for I64u values
  Silence GCC's "cast of pointer to integer of a different size" warning
  Squelch warning about an integer overflow

Merge branch 'jc/add-u-A-default-to-top' into maint

"git --literal-pathspecs add -u/-A" without any command line
argument misbehaved ever since Git 2.0.

* jc/add-u-A-default-to-top:
  add: simplify -u/-A without pathspec

Merge branch 'jk/delete-modechange-conflict' into maint

Merging a branch that removes a path and another that changes the
mode bits on the same path should have conflicted at the path, but
it didn't and silently favoured the removal.

* jk/delete-modechange-conflict:
  merge: detect delete/modechange conflict
  t6031: generalize for recursive and resolve strategies
  t6031: move triple-rename test to t3030

Merge branch 'js/imap-send-curl-compilation-fix' into maint

"git imap-send" did not compile well with older version of cURL library.

* js/imap-send-curl-compilation-fix:
  imap-send: only use CURLOPT_LOGIN_OPTIONS if it is actually available

Merge branch 'rp/link-curl-before-ssl' into maint

The linkage order of libraries was wrong in places around libcurl.

* rp/link-curl-before-ssl:
  configure.ac: detect ssl need with libcurl
  Makefile: make curl-config path configurable
  Makefile: link libcurl before zlib

Merge branch 'nd/clone-linked-checkout' into maint

It was not possible to use a repository-lookalike created by "git
worktree add" as a local source of "git clone".

* nd/clone-linked-checkout:
  clone: better error when --reference is a linked checkout
  clone: allow --local from a linked checkout
  enter_repo: allow .git files in strict mode
  enter_repo: avoid duplicating logic, use is_git_directory() instead
  t0002: add test for enter_repo(), non-strict mode
  path.c: delete an extra space

Merge branch 'sa/send-email-smtp-batch-data-limit' into maint

When "git send-email" wanted to talk over Net::SMTP::SSL,
Net::Cmd::datasend() did not like to be fed too many bytes at the
same time and failed to send messages.  Send the payload one line
at a time to work around the problem.

* sa/send-email-smtp-batch-data-limit:
  git-send-email.perl: Fixed sending of many/huge changes/patches

sha1: allow limiting the size of the data passed to SHA1_Update()

Using the previous commit's inredirection mechanism for SHA1,
support a chunked implementation of SHA1_Update() that limits the
amount of data in the chunk passed to SHA1_Update().

This is enabled by using the Makefile variable SHA1_MAX_BLOCK_SIZE
to specify chunk size.  When using Apple's CommonCrypto library this
is set to 1GiB (the implementation cannot handle more 4GiB).

Signed-off-by: Atousa Pahlevan Duprat <apahlevan@ieee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1: provide another level of indirection for the SHA-1 functions

The git source uses git_SHA1_Update() and friends to call into the
code that computes the hashes.  Traditionally, we used to map these
directly to underlying implementation of the SHA-1 hash (e.g.
SHA1_Update() from OpenSSL or blk_SHA1_Update() from block-sha1/).

This arrangement however makes it hard to tweak behaviour of the
underlying implementation without fully replacing.  If we want to
introduce a tweaked_SHA1_Update() wrapper to implement the "Update"
in a slightly different way, for example, the implementation of the
wrapper still would want to call into the underlying implementation,
but tweaked_SHA1_Update() cannot call git_SHA1_Update() to get to
the underlying implementation (often but not always SHA1_Update()).

Add another level of indirection that maps platform_SHA1_Update()
and friends to their underlying implementations, and by default make
git_SHA1_Update() and friends map to platform_SHA1_* functions.

Doing it this way will later allow us to map git_SHA1_Update() to
tweaked_SHA1_Update(), and the latter can use platform_SHA1_Update()
in its implementation.

Signed-off-by: Atousa Pahlevan Duprat <apahlevan@ieee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'xf/user-manual-ff' into maint

* xf/user-manual-ff:
  user-manual: fix the description of fast-forward

Merge branch 'xf/user-manual-markup' into maint

AsciiDoc markup fixes.

* xf/user-manual-markup:
  Documentation: match undefline with the text in old release notes
  Documentation: match underline with the text
  Documentation: fix header markup

Merge branch 'jc/everyday-markup' into maint

AsciiDoc markup fixes.

* jc/everyday-markup:
  Documentation/everyday: match undefline with the text

Merge branch 'jc/em-dash-in-doc' into maint

AsciiDoc markup fixes.

* jc/em-dash-in-doc:
  Documentation: AsciiDoc spells em-dash as double-dashes, not triple

Merge branch 'es/worktree-add' into maint

* es/worktree-add:
  worktree: usage: denote <branch> as optional with 'add'

gc: remove garbage .idx files from pack dir

Add a custom report_garbage handler to collect and remove
garbage .idx files from the pack directory.

Signed-off-by: Doug Kelly <dougk.ff7@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5304: test cleaning pack garbage

Pack garbage, noticeably stale .idx files, can be cleaned up during
a garbage collection.  This tests to ensure such garbage is properly
cleaned up.

Note that the prior test for checking pack garbage with count-objects
left some stale garbage after the test exited.  This has also been
corrected.

Signed-off-by: Doug Kelly <dougk.ff7@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'mk/blame-error-message' into maint

The error message from "git blame --contents --reverse" incorrectly
talked about "--contents --children".

* mk/blame-error-message:
  blame: fix option name in error message

Merge branch 'jk/merge-file-exit-code' into maint

"git merge-file" tried to signal how many conflicts it found, which
obviously would not work well when there are too many of them.

* jk/merge-file-exit-code:
  merge-file: clamp exit code to maximum 127

Merge branch 'dt/name-hash-dir-entry-fix' into maint

The name-hash subsystem that is used to cope with case insensitive
filesystems keeps track of directories and their on-filesystem
cases for all the paths in the index by holding a pointer to a
randomly chosen cache entry that is inside the directory (for its
ce->ce_name component).  This pointer was not updated even when the
cache entry was removed from the index, leading to use after free.
This was fixed by recording the path for each directory instead of
borrowing cache entries and restructuring the API somewhat.

* dt/name-hash-dir-entry-fix:
  name-hash: don't reuse cache_entry in dir_entry

Merge branch 'jc/am-3-fallback-regression-fix' into maint

"git am -3" had a small regression where it is aborted in its error
handling codepath when underlying merge-recursive failed in certain
ways, as it assumed that the internal call to merge-recursive will
never die, which is not the case (yet).

* jc/am-3-fallback-regression-fix:
  am -3: do not let failed merge from completing the error codepath

Merge branch 'jc/usage-stdin' into maint

The synopsis text and the usage string of subcommands that read
list of things from the standard input are often shown as if they
only take input from a file on a filesystem, which was misleading.

* jc/usage-stdin:
  usage: do not insist that standard input must come from a file

Merge branch 'rt/placeholder-in-usage' into maint

A couple of commands still showed "[options]" in their usage string
to note where options should come on their command line, but we
spell that "[<options>]" in most places these days.

* rt/placeholder-in-usage:
  am, credential-cache: add angle brackets to usage string

Merge branch 'dt/t7063-fix-flaky-test' into maint

* dt/t7063-fix-flaky-test:
  t7063: fix flaky untracked-cache test

Merge branch 'mk/submodule-gitdir-path' into maint

The submodule code has been taught to work better with separate
work trees created via "git worktree add".

* mk/submodule-gitdir-path:
  path: implement common_dir handling in git_pathdup_submodule()
  submodule refactor: use strbuf_git_path_submodule() in add_submodule_odb()

Merge branch 'nd/gc-auto-background-fix' into maint

When "git gc --auto" is backgrounded, its diagnosis message is
lost.  Save it to a file in $GIT_DIR and show it next time the "gc
--auto" is run.

* nd/gc-auto-background-fix:
  gc: save log from daemonized gc --auto and print it next time

Merge branch 'ls/p4-translation-failure' into maint

Work around "git p4" failing when the P4 depot records the contents
in UTF-16 without UTF-16 BOM.

* ls/p4-translation-failure:
  git-p4: handle "Translation of file content failed"
  git-p4: add test case for "Translation of file content failed" error

Merge branch 'gr/rebase-i-drop-warn' into maint

Recent update to "rebase -i" that tries to sanity check the edited
insn sheet before it uses it has become too picky on Windows where
CRLF left by the editor is turned into a trailing CR on the line
read via the "read" built-in command.

* gr/rebase-i-drop-warn:
  rebase-i: work around Windows CRLF line endings
  t3404: "rebase -i" gets broken when insn sheet uses CR/LF line endings

Merge branch 'js/clone-dissociate' into maint

"git clone --dissociate" runs a big "git repack" process at the
end, and it helps to close file descriptors that are open on the
packs and their idx files before doing so on filesystems that
cannot remove a file that is still open.

* js/clone-dissociate:
  clone --dissociate: avoid locking pack files
  sha1_file.c: add a function to release all packs
  sha1_file: consolidate code to close a pack's file descriptor
  t5700: demonstrate a Windows file locking issue with `git clone --dissociate`

Merge branch 'ld/p4-import-labels' into maint

Correct "git p4 --detect-labels" so that it does not fail to create
a tag that points at a commit that is also being imported.

* ld/p4-import-labels:
  git-p4: fix P4 label import for unprocessed commits
  git-p4: do not terminate creating tag for unknown commit
  git-p4: failing test for ignoring invalid p4 labels

Merge branch 'tk/stripspace' into maint

The internal stripspace() function has been moved to where it
logically belongs to, i.e. strbuf API, and the command line parser
of "git stripspace" has been updated to use the parse_options API.

* tk/stripspace:
  stripspace: use parse-options for command-line parsing
  strbuf: make stripspace() part of strbuf

Merge branch 'jk/repository-extension' into maint

Prepare for Git on-disk repository representation to undergo
backward incompatible changes by introducing a new repository
format version "1", with an extension mechanism.

* jk/repository-extension:
  introduce "preciousObjects" repository extension
  introduce "extensions" form of core.repositoryformatversion

daemon: plug memory leak

Call child_process_clear() when a child ends to release the memory
allocated for its environment.  This is necessary because unlike all
other users of start_command() we don't call finish_command(), which
would have taken care of that for us.

This leak was introduced by f063d38b (daemon: use cld->env_array
when re-spawning).

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

run-command: factor out child_process_clear()

Avoid duplication by moving the code to release allocated memory for
arguments and environment to its own function, child_process_clear().
Export it to provide a counterpart to child_process_init().

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

show-branch: use argv_array for default arguments

Use argv_array instead of open-coding it.

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

wt-status: use skip_prefix() to get rid of magic string length constants

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

wt-status: don't skip a magical number of characters blindly

Use the variable branch_name, which already has "refs/heads/" removed,
instead of blindly advancing in the ->branch string by 11 bytes.  This
is safer and less magical.

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

wt-status: avoid building bogus branch name with detached HEAD

If we're on a detached HEAD then wt_shortstatus_print_tracking() takes
the string "HEAD (no branch)", translates it, skips the first eleven
characters and passes the result to branch_get(), which returns a bogus
result and accesses memory out of bounds in order to produce it.
Somehow stat_tracking_info(), which is passed that result, does the
right thing anyway, i.e. it finds that there is no base.

Avoid the bogus results and memory accesses by checking for HEAD first
and exiting early in that case.  This fixes t7060 with --valgrind.

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

wt-status: exit early using goto in wt_shortstatus_print_tracking()

Deduplicate printing the line terminator by jumping to the end of the
function.

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

t7060: add test for status --branch on a detached HEAD

This test fails when run under Valgrind because branch_get() gets passed
a bogus branch name pointer:

==62831== Invalid read of size 1
==62831==    at 0x4F76AE: branch_get (remote.c:1650)
==62831==    by 0x53499E: wt_shortstatus_print_tracking (wt-status.c:1654)
==62831==    by 0x53499E: wt_shortstatus_print (wt-status.c:1706)
==62831==    by 0x428D29: cmd_status (commit.c:1384)
==62831==    by 0x405D6D: run_builtin (git.c:350)
==62831==    by 0x405D6D: handle_builtin (git.c:536)
==62831==    by 0x404F10: run_argv (git.c:582)
==62831==    by 0x404F10: main (git.c:690)
==62831==  Address 0x5e89b0b is 6 bytes after a block of size 5 alloc'd
==62831==    at 0x4C28C4F: malloc (vg_replace_malloc.c:299)
==62831==    by 0x59579E9: strdup (strdup.c:42)
==62831==    by 0x52E108: xstrdup (wrapper.c:43)
==62831==    by 0x5322A6: wt_status_prepare (wt-status.c:130)
==62831==    by 0x4276E0: status_init_config (commit.c:184)
==62831==    by 0x428BB8: cmd_status (commit.c:1350)
==62831==    by 0x405D6D: run_builtin (git.c:350)
==62831==    by 0x405D6D: handle_builtin (git.c:536)
==62831==    by 0x404F10: run_argv (git.c:582)
==62831==    by 0x404F10: main (git.c:690)

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

difftool: ignore symbolic links in use_wt_file

The caller is preparing a narrowed-down copy of the working tree and
this function is asked if the path should be included in that copy.
If we say yes, the path from the working tree will be either symlinked
or copied into the narrowed-down copy.

For any path that is a symbolic link, the caller later fixes up the
narrowed-down copy by unlinking the path and replacing it with a
regular file it writes out that mimics the way how "git diff"
compares symbolic links.

Let's answer "no, you do not want to copy/symlink the working tree
file" for all symbolic links from this function, as we know the
result will not be used because it will be overwritten anyway.

Incidentally, this also stops the function from feeding a symbolic
link in the working tree to hash-object, which is a wrong thing to
do to begin with. The link may be pointing at a directory, or worse
may be dangling (both would be noticed as an error).  Even if the
link points at a regular file, hashing the contents of a file that
is pointed at by the link is not correct (Git hashes the contents of
the link itself, not the pointee).

Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-file: clamp exit code to maximum 127

Git-merge-file is documented to return one of three exit
codes:

  - zero means the merge was successful

  - a negative number means an error occurred

  - a positive number indicates the number of conflicts

Unfortunately, this all gets stuffed into an 8-bit return
code. Which means that if you have 256 conflicts, this wraps
to zero, and the merge appears to succeed (and commits a
blob full of conflict-marker cruft!).

This patch clamps the return value to a maximum of 127,
which we should be able to safely represent everywhere. This
also leaves 128-255 for other values. Shells (and some parts
of git) will typically represent signal death as 128 plus
the signal number. And negative values are typically coerced
to an 8-bit unsigned value (so "return -1" ends up as 255).

Technically negative returns have the same problem (e.g.,
"-256" wraps back to 0), but this is not a problem in
practice, as the only negative value we use is "-1".

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

rebase-i: work around Windows CRLF line endings

Editors on Windows can and do save text files with CRLF line
endings, which is the convention on the platform.  We are seeing
reports that the "read" command in a port of bash to the environment
however does not strip the CRLF at the end, not adjusting for the
same convention on the platform.

This breaks the recently added sanity checks for the insn sheet fed
to "rebase -i"; instead of an empty line (hence nothing in $command),
the script was getting a lone CR in there.

Special case a lone CR and treat it the same way as an empty line to
work this around.

This patch (also) passes the test with Git for Windows, where the
issue was seen first.

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

t3404: "rebase -i" gets broken when insn sheet uses CR/LF line endings

Based on a bug report by Chad Boles.

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

add_submodule_odb: initialize alt_odb list earlier

The add_submodule_odb function tries to add a submodule's
object store as an "alternate". It needs the existing list
to be initialized (from the objects/info/alternates file)
for two reasons:

  1. We look for duplicates with the existing alternate
     stores, but obviously this doesn't work if we haven't
     loaded any yet.

  2. We link our new entry into the list by prepending it to
     alt_odb_list. But we do _not_ modify alt_odb_tail.
     This variable starts as NULL, and is a signal to the
     alt_odb code that the list has not yet been
     initialized.

     We then call read_info_alternates on the submodule (to
     recursively load its alternates), which will try to
     append to that tail, assuming it has been initialized.
     This causes us to segfault if it is NULL.

This rarely comes up in practice, because we will have
initialized the alt_odb any time we do an object lookup. So
you can trigger this only when:

  - you try to access a submodule (e.g., a diff with
    diff.submodule=log)

  - the access happens before any other object has been
    accessed (e.g., because the diff is between the working
    tree and the index)

  - the submodule contains an alternates file (so we try to
    add an entry to the NULL alt_odb_tail)

To fix this, we just need to call prepare_alt_odb at the
start of the function (and if we have already initialized,
it is a noop).

Note that we can remove the prepare_alt_odb call from the
end. It is guaranteed to be a noop, since we will have
called it earlier.

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

merge: detect delete/modechange conflict

If one side deletes a file and the other changes its
content, we notice and report a conflict. However, if
instead of changing the content, we change only the mode,
the merge does not notice (and the mode change is silently
dropped).

The trivial index merge notices the problem and correctly
leaves the conflict in the index, but both merge-recursive
and merge-one-file will silently resolve this in favor of
the deletion.  In many cases that is a sane resolution, but
we should be punting to the user whenever there is any
question. So let's detect and treat this as a conflict (in
both strategies).

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

t6031: generalize for recursive and resolve strategies

This script tests the filemode handling of merge-recursive,
but we do not test the same thing for merge-resolve. Let's
generalize the script a little:

  1. Break out the setup steps for each test into a separate
     snippet.

  2. For each test, run it twice; once with "-s recursive"
     and once with "-s resolve". We can avoid repeating
     ourselves by adding a function.

  3. Since we have a nice abstracted function, we can make
     our tests more thorough by testing both directions
     (change on "ours" versus "theirs").

This improves our test coverage, and will make this the
place to add more tests related to merging mode changes.

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

t6031: move triple-rename test to t3030

The t6031 test was introduced to check filemode handling of
merge-recursive. Much later, an unrelated test was tacked on
to look at renames and d/f conflicts. This test does not
depend on anything that happened before (it actually blows
away any existing content in the test repo). Let's move it
to t3030, where there are more related tests.

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

use pop_commit() for consuming the first entry of a struct commit_list

Instead of open-coding the function pop_commit() just call it.  This
makes the intent clearer and reduces code size.

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

Correct fscanf formatting string for I64u values

This fix is probably purely cosmetic because PRIuMAX is likely identical
to SCNuMAX. Nevertheless, when using a function of the scanf() family,
the correct interpolation to use is the latter, not the former.

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

Silence GCC's "cast of pointer to integer of a different size" warning

When calculating hashes from pointers, it actually makes sense to cut
off the most significant bits. In that case, said warning does not make
a whole lot of sense.

So let's just work around it by casting the pointer first to intptr_t
and then casting up/down to the final integral type.

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

Squelch warning about an integer overflow

We cannot rely on long integers to have more than 32 bits.

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

imap-send: only use CURLOPT_LOGIN_OPTIONS if it is actually available

This fixes the compilation on an older Linux that was used to debug
test failures when upgrading Git for Windows to Git v2.3.0.

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

blame: fix option name in error message

The option name used in blame's UI is `--reverse`.

Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual: fix the description of fast-forward

The "Fast-forward merges" section of user-manual.txt incorrectly
says if the current branch is a descendant of the other, Git will
perform a fast-forward merge, but it should the other way around.

Signed-off-by: Xue Fuqiao <xfq.free@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add: simplify -u/-A without pathspec

Since Git 2.0, "add -u" and "add -A" run from a subdirectory without
any pathspec mean "everything in the working tree" (before 2.0, they
were limited to the current directory).  The limiting to the current
directory was implemented by inserting "." to the command line when
the end user did not give us any pathspec.  At 2.0, we updated the
code to insert ":/" (instead of '.') to consider everything from the
top-level, by using a pathspec magic "top".

The call to parse_pathspec() using the command line arguments is,
however, made with PATHSPEC_PREFER_FULL option since 5a76aff1 (add:
convert to use parse_pathspec, 2013-07-14), which predates Git 2.0.
In retrospect, there was no need to turn "adding . to limit to the
directory" into "adding :/ to unlimit to everywhere" in Git 2.0;
instead we could just have done "if there is no pathspec on the
command line, just let it be".  The parse_pathspec() then would give
us a pathspec that matches everything and all is well.

Incidentally such a simplification also fixes a corner case bug that
stems from the fact that ":/" does not necessarily mean any magic.
A user would say "git --literal-pathspecs add -u :/" from the
command line when she has a directory ':' and wants to add
everything in it (and she knows that her :/ will be taken as
'everything under the sun' magic pathspec unless she disables the
magic with --literal-pathspecs).  The internal use of ':/' would
behave the same way as such an explicitly given ":/" when run with
"--literal-pathspecs", and will not add everything under the sun as
the code originally intended.

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

Documentation: AsciiDoc spells em-dash as double-dashes, not triple

Again, we do not usually process release notes with AsciiDoc, but it
is better to be consistent.

This incidentally reveals breakages left by an ancient 5e00439f
(Documentation: build html for all files in technical and howto,
2012-10-23).  The index-format documentation was originally written
to be read as straight text without formatting and when the commit
forced everything in Documentation/ to go through AsciiDoc, it did
not do any adjustment--hence the double-dashes will be seen in the
resulting text that is rendered as preformatted fixed-width without
converted into em-dashes.

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

Documentation: match undefline with the text in old release notes

These are not processed with AsciiDoc, but it is better to be
consistent.

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

Documentation: match underline with the text

Even though AsciiDoc is more lenient when deciding if an underline
is for the contents on the previous line to find section headers, we
should match the length of them for other formatters to help them.

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

Documentation/everyday: match undefline with the text

Even though AsciiDoc is more lenient when deciding if an underline
is for the contents on the previous line to find section headers, we
should match the length of them for other formatters to help them.

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

Documentation: fix header markup

Asciidoctor is stricter than AsciiDoc when deciding if underlining
is a section title or the start of preformatted text.  Make the
length of the underlining match the text to ensure that it renders
correctly in all implementations.

Signed-off-by: Xue Fuqiao <xfq.free@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

name-hash: don't reuse cache_entry in dir_entry

Stop reusing cache_entry in dir_entry; doing so causes a
use-after-free bug.

During merges, we free entries that we no longer need in the
destination index.  But those entries might have also been stored in
the dir_entry cache, and when a later call to add_to_index found them,
they would be used after being freed.

To prevent this, change dir_entry to store a copy of the name instead
of a pointer to a cache_entry.  This entails some refactoring of code
that expects the cache_entry.

Keith McGuigan <kmcguigan@twitter.com> diagnosed this bug and wrote
the initial patch, but this version does not use any of Keith's code.

Helped-by: Keith McGuigan <kmcguigan@twitter.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: David Turner <dturner@twopensource.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

configure.ac: detect ssl need with libcurl

When libcurl has been statically compiled with openssl support they both
need to be linked in everytime libcurl is used.

During configuration this can be detected by looking for Curl_ssl_init
function symbol in libcurl, which will only be present if libcurl has been
compiled statically built with openssl.

configure.ac checks for Curl_ssl_init function in libcurl and if such function
exists; it sets NEEDS_SSL_WITH_CURL that is used by the Makefile to include
-lssl alongside with -lcurl.

Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: make curl-config path configurable

There are situations, e.g. during cross compilation, where curl-config
program is not present in the PATH.

Make the makefile use a configurable curl-config program passed through
CURL_CONFIG variable which can be set through config.mak.

Also make this variable tunable through use of autoconf/configure. Configure
will set CURL_CONFIG variable in config.mak.autogen to whatever value has been
passed to ac_cv_prog_CURL_CONFIG.

Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: link libcurl before zlib

For static linking especially library order while linking is important. For
example, libcurl wants symbols from zlib when building http-push, http-fetch
and remote-curl. So for these programs libcurl has to be linked before zlib.

Signed-off-by: Remi Pommarel <repk@triplefau.lt>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'js/gc-with-stale-symref' into maint

"git gc" used to barf when a symbolic ref has gone dangling
(e.g. the branch that used to be your upstream's default when you
cloned from it is now gone, and you did "fetch --prune").

* js/gc-with-stale-symref:
  pack-objects: do not get distracted by broken symrefs
  gc: demonstrate failure with stale remote HEAD

Merge branch 'rd/test-path-utils' into maint

The normalize_ceiling_entry() function does not muck with the end
of the path it accepts, and the real world callers do rely on that,
but a test insisted that the function drops a trailing slash.

* rd/test-path-utils:
  test-path-utils.c: remove incorrect assumption

Merge branch 'jc/doc-gc-prune-now' into maint

"git gc" is safe to run anytime only because it has the built-in
grace period to protect young objects.  In order to run with no
grace period, the user must make sure that the repository is
quiescent.

* jc/doc-gc-prune-now:
  Documentation/gc: warn against --prune=<now>

Merge branch 'jk/filter-branch-use-of-sed-on-incomplete-line' into maint

A recent "filter-branch --msg-filter" broke skipping of the commit
object header, which is fixed.

* jk/filter-branch-use-of-sed-on-incomplete-line:
  filter-branch: remove multi-line headers in msg filter

t7063: fix flaky untracked-cache test

Dirty the test worktree's root directory, as the test expects.

When testing the untracked-cache, we previously assumed that checking
out master would be sufficient to mark the mtime of the worktree's
root directory as racily-dirty.  But sometimes, the checkout would
happen at 12345.999 seconds and the status at 12346.001 seconds,
meaning that the worktree's root directory would not be racily-dirty.
And since it was not truly dirty, occasionally the test would fail.
By making the root truly dirty, the test will always succeed.

Tested by running a few hundred times.

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

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

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

worktree: usage: denote <branch> as optional with 'add'

Although 1eb07d8 (worktree: add: auto-vivify new branch when
<branch> is omitted, 2015-07-06) updated the documentation when
<branch> became optional, it neglected to update the in-code
usage message. Fix this oversight.

Reported-by: ch3cooli@gmail.com
Signed-off-by: Sidhant Sharma <tigerkid001@gmail.com>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

usage: do not insist that standard input must come from a file

The synopsys text and the usage string of subcommands that read list
of things from the standard input are often shown like this:

git gostak [--distim] < <list-of-doshes>

This is problematic in a number of ways:

 * The way to use these commands is more often to feed them the
   output from another command, not feed them from a file.

 * Manual pages outside Git, commands that operate on the data read
   from the standard input, e.g "sort", "grep", "sed", etc., are not
   described with such a "< redirection-from-file" in their synopsys
   text.  Our doing so introduces inconsistency.

 * We do not insist on where the output should go, by saying

git gostak [--distim] < <list-of-doshes> > <output>

 * As it is our convention to enclose placeholders inside <braket>,
   the redirection operator followed by a placeholder filename
   becomes very hard to read, both in the documentation and in the
   help text.

Let's clean them all up, after making sure that the documentation
clearly describes the modes that take information from the standard
input and what kind of things are expected on the input.

[jc: stole example for fmt-merge-msg from Jonathan]

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

Git 2.6.2

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

Merge branch 'cc/quote-comments' into maint

A no-op code-health maintenance.

* cc/quote-comments:
  quote: move comment before sq_quote_buf()
  quote: fix broken sq_quote_buf() related comment

Merge branch 'es/worktree-add-cleanup' into maint

A no-op code-health maintenance.

* es/worktree-add-cleanup:
  t2026: rename worktree prune test

Merge branch 'tk/doc-interpret-trailers-grammo' into maint

* tk/doc-interpret-trailers-grammo:
  Documentation/interpret-trailers: Grammar fix

Merge branch 'tk/typofix-connect-unknown-proto-error' into maint

* tk/typofix-connect-unknown-proto-error:
  connect: fix typo in result string of prot_name()

Merge branch 'jk/asciidoctor-section-heading-markup-fix' into maint

* jk/asciidoctor-section-heading-markup-fix:
  Documentation: fix section header mark-up

Merge branch 'nd/ls-remote-does-not-have-u-option' into maint

* nd/ls-remote-does-not-have-u-option:
  ls-remote.txt: delete unsupported option

Merge branch 'jc/fsck-dropped-errors' into maint

There were some classes of errors that "git fsck" diagnosed to its
standard error that did not cause it to exit with non-zero status.

* jc/fsck-dropped-errors:
  fsck: exit with non-zero when problems are found

Merge branch 'sb/http-flaky-test-fix' into maint

A test script for the HTTP service had a timing dependent bug,
which was fixed.

* sb/http-flaky-test-fix:
  t5561: get rid of racy appending to logfile

Merge branch 'sb/perf-without-installed-git' into maint

Performance-measurement tests did not work without an installed Git.

* sb/perf-without-installed-git:
  t/perf: make runner work even if Git is not installed

Merge branch 'js/icase-wt-detection' into maint

On a case insensitive filesystems, setting GIT_WORK_TREE variable
using a random cases that does not agree with what the filesystem
thinks confused Git that it wasn't inside the working tree.

* js/icase-wt-detection:
  setup: fix "inside work tree" detection on case-insensitive filesystems

Merge branch 'pt/am-builtin' into maint

When "git am" was rewritten as a built-in, it stopped paying
attention to user.signingkey, which was fixed.

* pt/am-builtin:
  am: configure gpg at startup

Merge branch 'mm/detach-at-HEAD-reflog' into maint

After "git checkout --detach", "git status" reported a fairly
useless "HEAD detached at HEAD", instead of saying at which exact
commit.

* mm/detach-at-HEAD-reflog:
  status: don't say 'HEAD detached at HEAD'
  t3203: test 'detached at' after checkout --detach

Merge branch 'gr/rebase-i-drop-warn' into maint

"git rebase -i" had a minor regression recently, which stopped
considering a line that begins with an indented '#' in its insn
sheet not a comment, which is now fixed.

* gr/rebase-i-drop-warn:
  rebase-i: loosen over-eager check_bad_cmd check
  rebase-i: explicitly accept tab as separator in commands

Merge branch 'dt/log-follow-config' into maint

Description of the "log.follow" configuration variable in "git log"
documentation is now also copied to "git config" documentation.

* dt/log-follow-config:
  log: Update log.follow doc and add to config.txt

Merge branch 'ti/glibc-stdio-mutex-from-signal-handler' into maint

Allocation related functions and stdio are unsafe things to call
inside a signal handler, and indeed killing the pager can cause
glibc to deadlock waiting on allocation mutex as our signal handler
tries to free() some data structures in wait_for_pager().  Reduce
these unsafe calls.

* ti/glibc-stdio-mutex-from-signal-handler:
  pager: don't use unsafe functions in signal handlers

Merge branch 'jk/notes-dwim-doc' into maint

The way how --ref/--notes to specify the notes tree reference are
DWIMmed was not clearly documented.

* jk/notes-dwim-doc:
  notes: correct documentation of DWIMery for notes references

Merge branch 'jk/make-findstring-makeflags-fix' into maint

Customization to change the behaviour with "make -w" and "make -s"
in our Makefile was broken when they were used together.

* jk/make-findstring-makeflags-fix:
  Makefile: fix MAKEFLAGS tests with multiple flags

Merge branch 'jw/make-arflags-customizable' into maint

The Makefile always runs the library archiver with hardcoded "crs"
options, which was inconvenient for exotic platforms on which
people want to use programs with totally different set of command
line options.

* jw/make-arflags-customizable:
  Makefile: allow $(ARFLAGS) specified from the command line

Merge branch 'jk/connect-clear-env' into maint

The ssh transport, just like any other transport over the network,
did not clear GIT_* environment variables, but it is possible to
use SendEnv and AcceptEnv to leak them to the remote invocation of
Git, which is not a good idea at all.  Explicitly clear them just
like we do for the local transport.

* jk/connect-clear-env:
  git_connect: clarify conn->use_shell flag
  git_connect: clear GIT_* environment for ssh

Merge branch 'jk/blame-first-parent' into maint

"git blame --first-parent v1.0..v2.0" was not rejected but did not
limit the blame to commits on the first parent chain.

* jk/blame-first-parent:
  blame: handle --first-parent