Merge branch 'jk/init-core-worktree-at-root'

We avoid setting core.worktree when the repository location is the
".git" directory directly at the top level of the working tree, but
the code misdetected the case in which the working tree is at the
root level of the filesystem (which arguably is a silly thing to
do, but still valid).

* jk/init-core-worktree-at-root:
  init: don't set core.worktree when initializing /.git

Merge branch 'mh/show-branch-topic'

"git show-branch --topics HEAD" (with no other arguments) did not
do anything interesting.  Instead, contrast the given revision
against all the local branches by default.

* mh/show-branch-topic:
  show-branch: show all local heads when only giving one rev along --topics

Merge branch 'sb/line-log-plug-pairdiff-leak'

* sb/line-log-plug-pairdiff-leak:
  line-log.c: fix a memleak

Merge branch 'jc/diff-no-index-d-f'

The usual "git diff" when seeing a file turning into a directory
showed a patchset to remove the file and create all files in the
directory, but "git diff --no-index" simply refused to work.  Also,
when asked to compare a file and a directory, imitate POSIX "diff"
and compare the file with the file with the same name in the
directory, instead of refusing to run.

* jc/diff-no-index-d-f:
  diff-no-index: align D/F handling with that of normal Git
  diff-no-index: DWIM "diff D F" into "diff D/F F"

Merge branch 'bc/object-id'

Identify parts of the code that knows that we use SHA-1 hash to
name our objects too much, and use (1) symbolic constants instead
of hardcoded 20 as byte count and/or (2) use struct object_id
instead of unsigned char [20] for object names.

* bc/object-id:
  apply: convert threeway_stage to object_id
  patch-id: convert to use struct object_id
  commit: convert parts to struct object_id
  diff: convert struct combine_diff_path to object_id
  bulk-checkin.c: convert to use struct object_id
  zip: use GIT_SHA1_HEXSZ for trailers
  archive.c: convert to use struct object_id
  bisect.c: convert leaf functions to use struct object_id
  define utility functions for object IDs
  define a structure for object IDs

git-compat-util.h: implement a different ARRAY_SIZE macro for for safely deriving the size of array

To get number of elements in an array git use the ARRAY_SIZE macro
defined as:

       #define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0]))

The problem with it is a possibility of mistakenly passing to it a
pointer instead an array. The ARRAY_SIZE macro as conventionally
defined does not provide good type-safety and the open-coded
approach is more fragile, more verbose and provides no improvement in
type-safety.

Use instead a different but compatible ARRAY_SIZE() macro,
which will also break compile if you try to
use it on a pointer. This implemention revert to the original code
if the compiler doesn't know the typeof and __builtin_types_compatible_p
GCC extensions.

This can ensure our code is robust to changes, without
needing a gratuitous macro or constant. A similar
ARRAY_SIZE implementation also exists in the linux kernel.

Credits to Rusty Russell and his ccan library.

Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

daemon: unbreak NO_IPV6 build regression

When 01cec54e (daemon: deglobalize hostname information, 2015-03-07)
wrapped the global variables such as hostname inside a struct, it
forgot to convert one location that spelled "hostname" that needs to
be updated to "hi->hostname".

This was inside NO_IPV6 block, and was not caught by anybody.

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

prefix_path(): unconditionally free results in the callers

As of d089ebaa (setup: sanitize absolute and funny paths in
get_pathspec(), 2008-01-28), prefix_path() always returns a
newly allocated string, so callers should free its result.

Additionally, drop the const from variables to which the result of
the prefix_path() is assigned, so they can be free()'d without
having to cast-away the constness.

Signed-off-by: Stefan Beller <sbeller@google.com>
Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

write_sha1_file(): do not use a separate sha1[] array

In the beginning, write_sha1_file() did not have a way to tell the
caller the name of the object it wrote to the caller.  This was
changed in d6d3f9d0 (This implements the new "recursive tree"
write-tree., 2005-04-09) by adding the "returnsha1" parameter to the
function so that the callers who are interested in the value can
optionally pass a pointer to receive it.

It turns out that all callers do want to know the name of the object
it just has written.  Nobody passes a NULL to this parameter, hence
it is not necessary to use a separate sha1[] array to receive the
result from  write_sha1_file_prepare(), and copy the result to the
returnsha1 supplied by the caller.

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

t1007: add hash-object --literally tests

git-hash-object learned a --literally option in 5ba9a93
(hash-object: add --literally option, 2014-09-11). Check that
--literally allows object creation with a bogus type, with two
type strings whose length is reasonably short and very long.

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

hash-object --literally: fix buffer overrun with extra-long object type

"hash-object" learned in 5ba9a93 (hash-object: add --literally
option, 2014-09-11) to allow crafting a corrupt/broken object of
unknown type.

When the user-provided type is particularly long, however, it can
overflow the relatively small stack-based character array handed to
write_sha1_file_prepare() by hash_sha1_file() and write_sha1_file(),
leading to stack corruption (and crash).  Introduce a custom helper
to allow arbitrarily long typenames just for "hash-object --literally".

[jc: Eric's original used a strbuf in the more common codepaths, and
I rewrote it to avoid penalizing the non-literally code. Bugs are mine]

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

config: use error() instead of fprintf(stderr, ...)

The die() / error() / warning() helpers put a fatal: / error: /
warning: prefix in front of the error message they print describing
the message's severity, which users are likely to be accustomed to
seeing these days.

This change will also be useful when marking the message for
translation: the argument to error() includes no newline at the end,
so it is less fussy for translators to translate without lines running
together in the translated output.

While we're here, start the error messages with a lowercase letter to
match the usual typography of error messages.

A quick web search and a code search at codesearch.debian.net finds no
scripts trying to parse these error messages, so this change should be
safe.

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

git-hash-object.txt: document --literally option

Document the git-hash-object --literally option added by 5ba9a93
(hash-object: add --literally option, 2014-09-11).

While here, also correct a minor typesetting oversight.

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

completion: fix and update 'git log --decorate=' options

'git log --decorate=' understands the 'full', 'short' and 'no' options.
From these the completion script only offered 'short' and it offered
'long' instead of 'full'.

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

completion: remove redundant __git_compute_all_commands() call

During lazy-initialization of the lists of all commands and porcelain
commands the function __git_compute_all_commands() is called twice.  The
relevant part of the call sequence looks like this:

  __git_compute_porcelain_commands()
     __git_compute_all_commands()
        <finds list of all commands uninitialized>
        __git_list_all_commands()
        <initializes list of all commands>
     __git_list_porcelain_commands()
        __git_compute_all_commands()
           <finds list of all commands already initialized, does nothing>
        <filters porcelains from list of all commands>

Either one of the two calls could be removed and the initialization of
both command lists would still work as a whole, but let's remove the call
from __git_compute_porcelain_commands(), because this way
__git_list_porcelain_commands() will keep working in itself.

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

pathspec: avoid the need of "--" when wildcard is used

When "--" is lacking from the command line and a command can take
both revs and paths, the idea is if an argument can be seen as both
an extended SHA-1 and a path, then "--" is required or git refuses
to continue. It's currently implemented as:

 (1) if an argument is rev, then it must not exist in worktree

 (2) else, it must exist in worktree

 (3) else, "--" is required.

These rules work for literal paths, but when non-literal pathspec is
involved, it almost always requires the user to add "--" because it
fails (2) and (1) is really rarely met (take "*.c" for example, (1)
is met if there is a ref named "*.c").

This patch modifies the rules a bit by considering any valid (*)
wildcard pathspec "exist in worktree". The rules become:

 (1) if an arg is a rev, then it must either exist in worktree or
     not be a valid wildcard pathspec.

 (2) else, it either exists in worktree or is a wildcard pathspec

 (3) else, "--" is required.

With the new rules, "--" is not needed most of the time when
wildcard pathspec is involved.

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

blame: CRLF in the working tree and LF in the repo

A typical setup under Windows is to set core.eol to CRLF, and text
files are marked as "text" in .gitattributes, or core.autocrlf is
set to true.

After 4d4813a5 "git blame" no longer works as expected for such a
set-up.  Every line is annotated as "Not Committed Yet", even though
the working directory is clean.  This is because the commit removed
the conversion in blame.c for all files, with or without CRLF in the
repo.

Having files with CRLF in the repo and core.autocrlf=input is a
temporary situation, and the files, if committed as is, will be
normalized in the repo, which _will_ be a notable change.  Blaming
them with "Not Committed Yet" is the right result.  Revert commit
4d4813a5 which was a misguided attempt to "solve" a non-problem.

Add two test cases in t8003 to verify the correct CRLF conversion.

Suggested-By: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.4

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

merge: deprecate 'git merge <message> HEAD <commit>' syntax

We had this in "git merge" manual for eternity:

    'git merge' <msg> HEAD <commit>...

    [This] syntax (<msg> `HEAD` <commit>...) is supported for
    historical reasons.  Do not use it from the command line or in
    new scripts.  It is the same as `git merge -m <msg> <commit>...`.

With the update to "git merge" to make it understand what is
recorded in FETCH_HEAD directly, including Octopus merge cases, we
now can rewrite the use of this syntax in "git pull" with a simple
"git merge FETCH_HEAD".

Also there are quite a few fallouts in the test scripts, and it
turns out that "git cvsimport" also uses this old syntax to record
a merge.

Judging from this result, I would not be surprised if dropping the
support of the old syntax broke scripts people have written and been
relying on for the past ten years.  But at least we can start the
deprecation process by throwing a warning message when the syntax is
used.

With luck, we might be able to drop the support in a few years.

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

merge: handle FETCH_HEAD internally

The collect_parents() function now is responsible for

 1. parsing the commits given on the command line into a list of
    commits to be merged;

 2. filtering these parents into independent ones; and

 3. optionally calling fmt_merge_msg() via prepare_merge_message()
    to prepare an auto-generated merge log message, using fake
    contents that FETCH_HEAD would have had if these commits were
    fetched from the current repository with "git pull . $args..."

Make "git merge FETCH_HEAD" to be the same as the traditional

    git merge "$(git fmt-merge-msg <.git/FETCH_HEAD)" $commits

invocation of the command in "git pull", where $commits are the ones
that appear in FETCH_HEAD that are not marked as not-for-merge, by
making it do a bit more, specifically:

 - noticing "FETCH_HEAD" is the only "commit" on the command line
   and picking the commits that are not marked as not-for-merge as
   the list of commits to be merged (substitute for step #1 above);

 - letting the resulting list fed to step #2 above;

 - doing the step #3 above, using the contents of the FETCH_HEAD
   instead of fake contents crafted from the list of commits parsed
   in the step #1 above.

Note that this changes the semantics.  "git merge FETCH_HEAD" has
always behaved as if the first commit in the FETCH_HEAD file were
directly specified on the command line, creating a two-way merge
whose auto-generated merge log said "merge commit xyz".  With this
change, if the previous fetch was to grab multiple branches (e.g.
"git fetch $there topic-a topic-b"), the new world order is to
create an octopus, behaving as if "git pull $there topic-a topic-b"
were run.  This is a deliberate change to make that happen, and
can be seen in the changes to t3033 tests.

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

merge: decide if we auto-generate the message early in collect_parents()

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

merge: make collect_parents() auto-generate the merge message

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

merge: extract prepare_merge_message() logic out

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

merge: narrow scope of merge_names

In order to pass the list of parents to fmt_merge_msg(), cmd_merge()
uses this strbuf to create something that look like FETCH_HEAD that
describes commits that are being merged.  This is necessary only
when we are creating the merge commit message ourselves, but was
done unconditionally.

Move the variable and the logic to populate it to confine them in a
block that needs them.

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

merge: split reduce_parents() out of collect_parents()

The latter does two separate things:

 - Parse the list of commits on the command line, and formulate the
   list of commits to be merged (including the current HEAD);

 - Compute the list of parents to be recorded in the resulting merge
   commit.

Split the latter into a separate helper function, so that we can
later supply the list commits to be merged from a different source
(namely, FETCH_HEAD).

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

merge: clarify collect_parents() logic

Clarify this small function in three ways.

 - The function initially collects all commits to be merged into a
   commit_list "remoteheads"; the "remotes" pointer always points at
   the tail of this list (either the remoteheads variable itself, or
   the ->next slot of the element at the end of the list) to help
   elongate the list by repeated calls to commit_list_insert().
   Because the new element appended by commit_list_insert() will
   always have its ->next slot NULLed out, there is no need for us
   to assign NULL to *remotes to terminate the list at the end.

 - The variable "head_subsumed" always confused me every time I read
   this code.  What is happening here is that we inspect what the
   caller told us to merge (including the current HEAD) and come up
   with the list of parents to be recorded for the resulting merge
   commit, omitting commits that are ancestor of other commits.
   This filtering may remove the current HEAD from the resulting
   parent list---and we signal that fact with this variable, so that
   we can later record it as the first parent when "--no-ff" is in
   effect.

 - The "parents" list is created for this function by reduce_heads()
   and was not deallocated after its use, even though the loop
   control was written in such a way to allow us to do so by taking
   the "next" element in a separate variable so that it can be used
   in the next-step part of the loop control.

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

merge: small leakfix and code simplification

When parsing a merged object name like "foo~20" to formulate a merge
summary "Merge branch foo (early part)", a temporary strbuf is used,
but we forgot to deallocate it when we failed to find the named
branch.

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

merge: do not check argc to determine number of remote heads

To reject merging multiple commits into an unborn branch, we check
argc, thinking that collect_parents() that reads the remaining
command line arguments from <argc, argv> will give us the same
number of commits as its input, i.e. argc.

Because what we really care about is the number of commits, let the
function run and then make sure it returns only one commit instead.

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

merge: clarify "pulling into void" special case

Instead of having it as one of the three if/elseif/.. case arms,
test the condition and handle this special case upfront.  This makes
it easier to follow the flow of logic.

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

t5520: test pulling an octopus into an unborn branch

The code comment for "git merge" in builtin/merge.c, we say

    If the merged head is a valid one there is no reason
    to forbid "git merge" into a branch yet to be born.
    We do the same for "git pull".

and t5520 does have an existing test for that behaviour.  However,
there was no test to make sure that 'git pull' to pull multiple
branches into an unborn branch must fail.

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

t5520: style fixes

Fix style funnies in early part of this test script that checks "git
pull" into an unborn branch.  The primary change is that 'chdir' to
a newly created empty test repository is now protected by being done
in a subshell to make it more robust without having to chdir back to
the original place.

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

merge: simplify code flow

One of the first things cmd_merge() does is to see if the "--abort"
option is given and run "reset --merge" and exit.  When the control
reaches this point, we know "--abort" was not given.

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

merge: test the top-level merge driver

We seem to have tests for specific merge strategy backends
(e.g. recursive), but not much test coverage for the "git merge"
itself.  As I am planning to update the semantics of merging
"FETCH_HEAD" in such a way that these two

    git pull . topic_a topic_b...

vs.

    git fetch . topic_a topic_b...
    git merge FETCH_HEAD

are truly equivalent, let me add a few test cases to cover the
tricky ones.

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

filter-branch: avoid passing commit message through sed

On some systems (like OS X), if sed encounters input without
a trailing newline, it will silently add it. As a result,
"git filter-branch" on such systems may silently rewrite
commit messages that omit a trailing newline. Even though
this is not something we generate ourselves with "git
commit", it's better for filter-branch to preserve the
original data as closely as possible.

We're using sed here only to strip the header fields from
the commit object. We can accomplish the same thing with a
shell loop. Since shell "read" calls are slow (usually one
syscall per byte), we use "cat" once we've skipped past the
header. Depending on the size of your commit messages, this
is probably faster (you pay the cost to fork, but then read
the data in saner-sized chunks). This idea is shamelessly
stolen from Junio.

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

rebase -i: redo tasks that die during cherry-pick

When rebase--interactive processes a task, it removes the item from
the todo list and appends it to another list of executed tasks. If a
pick (this includes squash and fixup) fails before the index has
recorded the changes, take the corresponding item and put it on the todo
list again. Otherwise, the changes introduced by the scheduled commit
would be lost.

That kind of decision is possible since the cherry-pick command
signals why it failed to apply the changes of the given commit. Either
the changes are recorded in the index using a conflict (return value 1)
and rebase does not continue until they are resolved or the changes
are not recorded in the index (return value neither 0 nor 1) and
rebase has to try again with the same task.

Add a test cases for regression testing to the "rebase-interactive"
test suite.

Signed-off-by: Fabian Ruch <bafain@gmail.com>
Signed-off-by: Phil Hord <hordp@cisco.com>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test-lib: turn on GIT_TEST_CHAIN_LINT by default

Now that the feature has had time to prove itself, and any
topics in flight have had a chance to clean up any broken
&&-chains, we can flip this feature on by default. This
makes one less thing submitters need to configure or check
before sending their patches.

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

t7502-commit.sh: fix a broken and-chain

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

connect: improve check for plink to reduce false positives

The git_connect function has code to handle plink and tortoiseplink
specially, as they require different command line arguments from
OpenSSH (-P instead of -p for ports; tortoiseplink additionally requires
-batch).  However, the match was done by checking for "plink" anywhere
in the string, which led to a GIT_SSH value containing "uplink" being
treated as an invocation of putty's plink.

Improve the check by looking for "plink" or "tortoiseplink" (or those
names suffixed with ".exe") only in the final component of the path.
This has the downside that a program such as "plink-0.63" would no
longer be recognized, but the increased robustness is likely worth it.
Add tests to cover these cases to avoid regressions.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5601: fix quotation error leading to skipped tests

One of the tests in t5601 used single quotes to delimit an argument
containing spaces.  However, this caused test_expect_success to be
passed three arguments instead of two, which in turn caused the test
name to be treated as a prerequisite instead of a test name.  As there
was no prerequisite called "bracketed hostnames are still ssh", the test
was always skipped.

Because this test was always skipped, the fact that it passed the
arguments in the wrong order was obscured.  Use double quotes inside the
test and reorder the arguments so that the test runs and properly
reflects the arguments that are passed to ssh.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

connect: simplify SSH connection code path

The code path used in git_connect pushed the majority of the SSH
connection code into an else block, even though the if block returns.
Simplify the code by eliminating the else block, as it is unneeded.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

test: validate prerequistes syntax

Brian Carson noticed that a test piece in t5601 had a pair of single
quotes in the body, which made it into 4 parameter call to
test_expect_success, as if its test title were a prerequisite.

As the prerequisites have a specific syntax (i.e. comma separated
tokens spelled in capital letters, possibly prefixed with ! for
negation), validate them to catch such a mistake in the future.

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

Merge branch 'mh/multimail-renewal'

* mh/multimail-renewal:
  Update git-multimail to version 1.0.2

Merge branch 'mg/show-notes-doc'

Documentation fix.

* mg/show-notes-doc:
  rev-list-options.txt: complete sentence about notes matching

Merge branch 'nd/versioncmp-prereleases'

* nd/versioncmp-prereleases:
  git tag: mention versionsort.prereleaseSuffix in manpage

Merge branch 'mg/status-v-v'

* mg/status-v-v:
  status: document the -v/--verbose option

git-p4: add failing tests for case-folding p4d

When p4d runs on a case-folding OS, git-p4 can end up getting
very confused. This adds failing tests to demonstrate the problem.

Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: t9814: prevent --chain-lint failure

Use test_lazy_prereq to setup prerequisites for the p4 move
test. This both makes the test simpler and clearer, and also
means it no longer fails the new --chain-lint tests.

Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase: silence "git checkout" for noop rebase

When the branch to be rebased is already up to date, we
"git checkout" the branch, print an "up to date" message,
and end the rebase early. However, our checkout may print
"Switched to branch 'foo'" or "Already on 'foo'", even if
the user has asked for "--quiet".

We should avoid printing these messages at all, "--quiet" or
no. Since the rebase is a noop, this checkout can be seen as
optimizing out these other two checkout operations (that
happen in a real rebase):

  1. Moving to the detached HEAD to start the rebase; we
     always feed "-q" to checkout there, and instead rely on
     our own custom message (which respects --quiet).

  2. Finishing a rebase, where we move to the final branch.
     Here we actually use update-ref rather than
     git-checkout, and produce no messages.

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

Update git-multimail to version 1.0.2

The only changes are to the README files, most notably the list of
maintainers and the project URL.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Sync with 2.3.7

Git 2.3.7

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

Merge branch 'tb/connect-ipv6-parse-fix' into maint

An earlier update to the parser that disects a URL broke an
address, followed by a colon, followed by an empty string (instead
of the port number), e.g. ssh://example.com:/path/to/repo.

* tb/connect-ipv6-parse-fix:
  connect.c: ignore extra colon after hostname

Merge branch 'ma/bash-completion-leaking-x' into maint

The completion script (in contrib/) contaminated global namespace
and clobbered on a shell variable $x.

* ma/bash-completion-leaking-x:
  completion: fix global bash variable leak on __gitcompappend

Merge branch 'jc/push-cert' into maint

The "git push --signed" protocol extension did not limit what the
"nonce" that is a server-chosen string can contain or how long it
can be, which was unnecessarily lax.  Limit both the length and the
alphabet to a reasonably small space that can still have enough
entropy.

* jc/push-cert:
  push --signed: tighten what the receiving end can ask to sign

Documentation: clarify how "git commit" cleans up the edited log message

The `-v` shows a unified diff in the editor to edit the commit
message to help the user to describe the change.  The diff is
stripped and will not become a part of the commit message.

Add a note about this with the `-v` description and slightly modify
the description for the default `--cleanup` mode.

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

t0027: Add repoMIX and LF_nul

"new safer autocrlf handling":

  - Check if eols in a file are converted at commit, when the file has
    CR (or CRLF) in the repo (technically speaking in the index).
  - Add a test-file repoMIX with mixed line-endings.
  - When converting LF->CRLF or CRLF->LF: check the warnings

checkout_files():

  - Checking out CRLF_nul and checking for eol coversion does not
    make much sense (CRLF will stay CRLF).
  - Use the file LF_nul instead: It is handled a binary in "auto" modes,
    and when declared as text the LF may be replaced with CRLF, depending
    on the configuration.

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

status: document the -v/--verbose option

Document `git status -v`, including its new doubled `-vv` form.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

RelNotes: wordsmithing

Make many textual tweaks to the 2.4.0 release notes.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

RelNotes: refer to the rebase -i "todo list", not "insn sheet"

"Todo list" is the name that is used in the user-facing documentation.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

RelNotes: correct name of versionsort.prereleaseSuffix

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git tag: mention versionsort.prereleaseSuffix in manpage

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-p4: improve client path detection when branches are used

Perforce allows client side file/directory remapping through
the use of the client view definition that is part of the
user's client spec.

To support this functionality while branch detection is
enabled it is important to determine the branch location in
the workspace such that the correct files are patched before
Perforce submission. Perforce provides a command that
facilitates this process: p4 where.

This patch does two things to fix improve file location
detection when git-p4 has branch detection and use of client
spec enabled:

 1. Enable usage of "p4 where" when Perforce branches exist
    in the git repository, even when client specification is
    used. This makes use of the already existing function
    p4Where.

 2. Allow identifying partial matches of the branch's depot
    path while processing the output of "p4 where". For
    robustness, paths will only match if ending in "/...".

Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ignore: info/exclude should trump core.excludesfile

$GIT_DIR/info/exclude and core.excludesfile (which falls back to
$XDG_HOME/git/ignore) are both ways to override the ignore pattern
lists given by the project in .gitignore files.  The former, which
is per-repository personal preference, should take precedence over
the latter, which is a personal preference default across different
repositories that are accessed from that machine.  The existing
documentation also agrees.

However, the precedence order was screwed up between these two from
the very beginning when 896bdfa2 (add: Support specifying an
excludes file with a configuration variable, 2007-02-27) introduced
core.excludesfile variable.

Noticed-by: Yohei Endo <yoheie@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.4.0-rc3

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

stop putting argv[0] dirname at front of PATH

When the "git" wrapper is invoked, we prepend the baked-in
exec-path to our PATH, so that any sub-processes we exec
will all find the git-foo commands that match the wrapper
version.

If you invoke git with an absolute path, like:

  /usr/bin/git foo

we also prepend "/usr/bin" to the PATH. This was added long
ago by by 231af83 (Teach the "git" command to handle some
commands internally, 2006-02-26), with the intent that
things would just work if you did something like:

  cd /opt
  tar xzf premade-git-package.tar.gz
  alias git=/opt/git/bin/git

as we would then find all of the related external commands
in /opt/git/bin. I.e., it made git runtime-relocatable,
since at the time of 231af83, we installed all of the git
commands into $(bindir). But these days, that is not enough.
Since f28ac70 (Move all dashed-form commands to libexecdir,
2007-11-28), we do not put commands into $(bindir), and you
actually need to convert "/usr/bin" into "/usr/libexec". And
not just for finding binaries; we want to find $(sharedir),
etc, the same way.  The RUNTIME_PREFIX build knob does this
the right way, by assuming a sane hierarchy rooted at
"$prefix" when we run "$prefix/bin/git", and inferring
"$prefix/libexec/git-core", etc.

So this feature (prepending the argv[0] dirname to the PATH)
is broken for providing a runtime prefix, and has been for
many years. Does it do anything for other cases?

For the "git" wrapper itself, as well as any commands
shipped by "git", the answer is no. Those are already in
git's exec-path, which is consulted first. For third-party
commands which you've dropped into the same directory, it
does include them. So if you do

  cd /opt
  tar xzf git-built-specifically-for-opt-git.tar.gz
  cp third-party/git-foo /opt/git/bin/git-foo
  alias git=/opt/git/bin/git

it does mean that we will find the third-party "git-foo",
even if you do not put /opt/git/bin into your $PATH. But
the flipside of this is that we will bump the precedence of
_other_ third-party tools that happen to be in the same
directory as git. For example, consider this setup:

  1. Git is installed by the system in /usr/bin. There are
     other system utilities in /usr/bin. E.g., a system
     "vi".

  2. The user installs tools they prefer in /usr/local/bin.
     E.g., vim with a "vi" symlink. They set their PATH to
     /usr/local/bin:/usr/bin to prefer their custom tools.

  3. Running /usr/bin/git puts "/usr/bin" at the front of
     their PATH. When git invokes the editor on behalf of
     the user, they get the system vi, not their normal vim.

There are other variants of this, including overriding
system ruby and python (which is quite common using tools
like "rvm" and "virtualenv", which use relocatable
hierarchies and $PATH settings to get a consistent
environment).

Given that the main motivation for git placing the argv[0]
dirname into the PATH has been broken for years, that the
remaining cases are obscure and unlikely (and easily fixed
by the user just setting up their $PATH sanely), and that
the behavior is hurting real, reasonably common use cases,
it's not worth continuing to do so.

Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

stash: require a clean index to apply

If you have staged contents in your index and run "stash
apply", we may hit a conflict and put new entries into the
index. Recovering to your original state is difficult at
that point, because tools like "git reset --keep" will blow
away anything staged.  We can make this safer by refusing to
apply when there are staged changes.

It's possible we could provide better tooling here, as "git
stash apply" should be writing only conflicts to the index
(so we know that any stage-0 entries are potentially
precious). But it is the odd duck; most "mergy" commands
will update the index for cleanly merged entries, and it is
not worth updating our tooling to support this use case
which is unlikely to be of interest (besides which, we would
still need to block a dirty index for "stash apply --index",
since that case _would_ be ambiguous).

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

t3903: avoid applying onto dirty index

One of the tests in t3903 wants to make sure that applying a
stash that touches only "file" can still happen even if there
are working tree changes to "other-file". To do so, it adds
"other-file" to the index (since otherwise it is an
untracked file, voiding the purpose of the test).

But as we are about to refactor the dirty-index handling,
and as this test does not actually care about having a dirty
index (only a dirty working tree), let's bump the tracking
of "other-file" into the setup phase, so we can have _just_
a dirty working tree here.

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

t3903: stop hard-coding commit sha1s

When testing the diff output of "git stash list", we look
for the stash's subject of "WIP on master: $sha1", even
though it's not relevant to the diff output. This makes the
test brittle to refactoring, as any changes to earlier tests
may impact the commit sha1.

Since we don't care about the commit subject here, we can
simply ask stash not to print it.

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

t9801: check git-p4's branch detection with client spec enabled

Add failing scenario when branch detection (--detect-branches) is
enabled together with use client spec (--use-client-spec). In this
specific scenario git-p4 will break when the Perforce client view
removes part of the depot path, as in the following example:

  //depot/branch1/base/... //client/branch1/...

The test case also includes an extra sub-file mapping to enforce
robustness check of git-p4's client view support:

  //depot/branch1/base/dir/sub_file1 //client/branch1/sub_file1

Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Sync with maint

Git 2.3.6

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

Merge branch 'jk/colors' into maint

"diff-highlight" (in contrib/) used to show byte-by-byte
differences, which meant that multi-byte characters can be chopped
in the middle.  It learned to pay attention to character boundaries
(assuming the UTF-8 payload).

* jk/colors:
  diff-highlight: do not split multibyte characters

Merge branch 'jk/test-annoyances' into maint

Test fixes.

* jk/test-annoyances:
  t5551: make EXPENSIVE test cheaper
  t5541: move run_with_cmdline_limit to test-lib.sh
  t: pass GIT_TRACE through Apache
  t: redirect stderr GIT_TRACE to descriptor 4
  t: translate SIGINT to an exit

Merge branch 'pt/enter-repo-comment-fix' into maint

Documentation update.

* pt/enter-repo-comment-fix:
  enter_repo(): fix docs to match code

Merge branch 'jz/gitweb-conf-doc-fix' into maint

Documentation update.

* jz/gitweb-conf-doc-fix:
  gitweb.conf.txt: say "build-time", not "built-time"

Merge branch 'jk/cherry-pick-docfix' into maint

* jk/cherry-pick-docfix:
  cherry-pick: fix docs describing handling of empty commits

Merge branch 'iu/fix-parse-options-h-comment' into maint

* iu/fix-parse-options-h-comment:
  parse-options.h: OPTION_{BIT,SET_INT} do not store pointer to defval

Merge branch 'jg/cguide-we-cannot-count' into maint

* jg/cguide-we-cannot-count:
  CodingGuidelines: update 'rough' rule count

Merge branch 'jk/pack-corruption-post-mortem' into maint

Documentation update.

* jk/pack-corruption-post-mortem:
  howto: document more tools for recovery corruption

Merge branch 'jn/doc-fast-import-no-16-octopus-limit' into maint

Documentation update.

* jn/doc-fast-import-no-16-octopus-limit:
  fast-import doc: remove suggested 16-parent limit

RelNotes: "merge --quiet" change has been reverted

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

Hopefully the last batch for 2.4

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

Merge branch 'ps/grep-help-all-callback-arg'

Code clean-up.

* ps/grep-help-all-callback-arg:
  grep: correctly initialize help-all option

Merge branch 'tb/connect-ipv6-parse-fix'

An earlier update to the parser that disects an address broke an
address, followed by a colon, followed by an empty string (instead
of the port number).

* tb/connect-ipv6-parse-fix:
  connect.c: ignore extra colon after hostname

Merge branch 'va/fix-git-p4-tests'

Test fixes for git-p4.

* va/fix-git-p4-tests:
  t9814: guarantee only one source exists in git-p4 copy tests
  git-p4: fix copy detection test
  t9814: fix broken shell syntax in git-p4 rename test

Merge branch 'jc/push-cert'

The "git push --signed" protocol extension did not limit what the
"nonce" that is a server-chosen string can contain or how long it
can be, which was unnecessarily lax.  Limit both the length and the
alphabet to a reasonably small space that can still have enough
entropy.

* jc/push-cert:
  push --signed: tighten what the receiving end can ask to sign

Merge branch 'ma/bash-completion-leaking-x'

The completion script (in contrib/) contaminated global namespace
and clobbered on a shell variable $x.

* ma/bash-completion-leaking-x:
  completion: fix global bash variable leak on __gitcompappend

fmt-merge-msg: plug small leak of commit buffer

A broken or badly formatted commit might not record author or
committer lines or we may not find a valid name on them.  The
function record_person() returned after calling get_commit_buffer()
without calling unuse_commit_buffer() on the memory it obtained in
such cases, potentially leaking it.

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

sha1_file: only freshen packs once per run

Since 33d4221 (write_sha1_file: freshen existing objects,
2014-10-15), we update the mtime of existing objects that we
would have written out (had they not existed). For the
common case in which many objects are packed, we may update
the mtime on a single packfile repeatedly. This can result
in a noticeable performance problem if calling utime() is
expensive (e.g., because your storage is on NFS).

We can fix this by keeping a per-pack flag that lets us
freshen only once per program invocation.

An alternative would be to keep the packed_git.mtime flag up
to date as we freshen, and freshen only once every N
seconds. In practice, it's not worth the complexity. We are
racing against prune expiration times here, which inherently
must be set to accomodate reasonable program running times
(because they really care about the time between an object
being written and it becoming referenced, and the latter is
typically the last step a program takes).

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

sha1_file: freshen pack objects before loose

When writing out an object file, we first check whether it
already exists and if so optimize out the write. Prior to
33d4221, we did this by calling has_sha1_file(), which will
check for packed objects followed by loose. Since that
commit, we check loose objects first.

For the common case of a repository whose objects are mostly
packed, this means we will make a lot of extra access()
system calls checking for loose objects. We should follow
the same packed-then-loose order that all of our other
lookups use.

Reported-by: Stefan Saasen <ssaasen@atlassian.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

reachable: only mark local objects as recent

When pruning and repacking a repository that has an
alternate object store configured, we may traverse a large
number of objects in the alternate. This serves no purpose,
and may be expensive to do. A longer explanation is below.

Commits d3038d2 and abcb865 taught prune and pack-objects
(respectively) to treat "recent" objects as tips for
reachability, so that we keep whole chunks of history. They
built on the object traversal in 660c889 (sha1_file: add
for_each iterators for loose and packed objects,
2014-10-15), which covers both local and alternate objects.

In both cases, covering alternate objects is unnecessary, as
both commands can only drop objects from the local
repository. In the case of prune, we traverse only the local
object directory. And in the case of repacking, while we may
or may not include local objects in our pack, we will never
reach into the alternate with "repack -d". The "-l" option
is only a question of whether we are migrating objects from
the alternate into our repository, or leaving them
untouched.

It is possible that we may drop an object that is depended
upon by another object in the alternate. For example,
imagine two repositories, A and B, with A pointing to B as
an alternate. Now imagine a commit that is in B which
references a tree that is only in A. Traversing from recent
objects in B might prevent A from dropping that tree. But
this case isn't worth covering. Repo B should take
responsibility for its own objects. It would never have had
the commit in the first place if it did not also have the
tree, and assuming it is using the same "keep recent chunks
of history" scheme, then it would itself keep the tree, as
well.

So checking the alternate objects is not worth doing, and
come with a significant performance impact. In both cases,
we skip any recent objects that have already been marked
SEEN (i.e., that we know are already reachable for prune, or
included in the pack for a repack). So there is a slight
waste of time in opening the alternate packs at all, only to
notice that we have already considered each object. But much
worse, the alternate repository may have a large number of
objects that are not reachable from the local repository at
all, and we end up adding them to the traversal.

We can fix this by considering only local unseen objects.

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

git-p4: use -m when running p4 changes

Simply running "p4 changes" on a large branch can result in a "too
many rows scanned" error from the Perforce server. It is better to
use a sequence of smaller calls to "p4 changes", using the "-m"
option to limit the size of each call.

Signed-off-by: Lex Spoon <lex@lexspoon.org>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

log -L: improve error message on malformed argument

The old message did not mention the :regex:file form.

To avoid overly long lines, split the message into two lines (in case
item->string is long, it will be the only part truncated in a narrow
terminal).

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

Documentation: change -L:<regex> to -L:<funcname>

The old wording was somehow implying that <start> and <end> were not
regular expressions. Also, the common case is to use a plain function
name here so <funcname> makes sense (the fact that it is a regular
expression is documented in line-range-format.txt).

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

Merge tag 'gitgui-0.20.0' of repo.or.cz/r/git-gui

git-gui 0.20.0

* tag 'gitgui-0.20.0' of http://repo.or.cz/r/git-gui:
  git-gui: set version 0.20
  git-gui: sv.po: Update Swedish translation (547t0f0u)
  git-gui i18n: Updated Bulgarian translation (547t,0f,0u)
  git-gui: Makes chooser set 'gitdir' to the resolved path
  git-gui: Fixes chooser not accepting gitfiles
  git-gui: reinstate support for Tcl 8.4
  git-gui: fix problem with gui.maxfilesdisplayed
  git-gui: fix verbose loading when git path contains spaces.
  git-gui/gitk: Do not depend on Cygwin's "kill" command on Windows
  git-gui: add configurable tab size to the diff view
  git-gui: Make git-gui lib dir configurable at runime
  git-gui i18n: Updated Bulgarian translation (520t,0f,0u)
  L10n: vi.po (543t): Init translation for Vietnamese
  git-gui: align the new recursive checkbox with the radiobuttons.
  git-gui: Add a 'recursive' checkbox in the clone menu.

t1509: update prepare script to be able to run t1509 in chroot again

Tested on Gentoo and OpenSUSE 13.1, both x86-64

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

index-pack: kill union delta_base to save memory

Once we know the number of objects in the input pack, we allocate an
array of nr_objects of struct delta_entry. On x86-64, this struct is
32 bytes long. The union delta_base, which is part of struct
delta_entry, provides enough space to store either ofs-delta (8 bytes)
or ref-delta (20 bytes).

Because ofs-delta encoding is more efficient space-wise and more
performant at runtime than ref-delta encoding, Git packers try to use
ofs-delta whenever possible, and it is expected that objects encoded
as ref-delta are minority.

In the best clone case where no ref-delta object is present, we waste
(20-8) * nr_objects bytes because of this union. That's about 38MB out
of 100MB for deltas[] with 3.4M objects, or 38%. deltas[] would be
around 62MB without the waste.

This patch attempts to eliminate that. deltas[] array is split into
two: one for ofs-delta and one for ref-delta. Many functions are also
duplicated because of this split. With this patch, ofs_deltas[] array
takes 51MB. ref_deltas[] should remain unallocated in clone case (0
bytes). This array grows as we see ref-delta. We save about half in
this case, or 25% of total bookkeeping.

The saving is more than the calculation above because some padding in
the old delta_entry struct is removed. ofs_delta_entry is 16 bytes,
including the 4 bytes padding. That's 13MB for padding, but packing
the struct could break platforms that do not support unaligned
access. If someone on 32-bit is really low on memory and only deals
with packs smaller than 2G, using 32-bit off_t would eliminate the
padding and save 27MB on top.

A note about ofs_deltas allocation. We could use ref_deltas memory
allocation strategy for ofs_deltas. But that probably just adds more
overhead on top. ofs-deltas are generally the majority (1/2 to 2/3) in
any pack. Incremental realloc may lead to too many memcpy. And if we
preallocate, say 1/2 or 2/3 of nr_objects initially, the growth rate
of ALLOC_GROW() could make this array larger than nr_objects, wasting
more memory.

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

t0027: support NATIVE_CRLF platforms

t0027 expects the native end-of-lines to be a single line feed
character.  On Windows, however, we set it to a carriage return
character followed by a line feed character.  Thus, we have to
modify t0027 to expect different warnings depending on the
end-of-line markers.

Adjust the check of the warnings and use these macros:

  WILC:  Warn if LF becomes CRLF
  WICL:  Warn if CRLF becomes LF
  WAMIX: Mixed line endings: either CRLF->LF or LF->CRLF

Improve the information given by check_warning().

Use test_cmp to show which warning is missing (or shouldn't be
there).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0027: cleanup: rename functions; avoid non-leading TABs

Make more clear what the tests are doing:

  commit_check_warn():
    Commit files and checks for conversion warnings.
    Old name: create_file_in_repo()

  checkout_files():
    Checkout files from the repo and check if they have
    the appropriate line endings in the work space.
    Old name: check_files_in_ws()

Replace non-leading TABS with spaces

Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-gui: set version 0.20

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>