Documentation/git-worktree: associate options with commands

git-worktree options affect some worktree commands but not others, but
this is not necessarily obvious from the option descriptions. Make this
clear by indicating explicitly which commands are affected by which
options.

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation/git-checkout: fix incorrect worktree prune command

This was missed when "git prune --worktrees" became "git worktree prune".

Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation/branch: document -M and -D in terms of --force

Now that we have proper documentation for --force's interaction with -d
and -m, we can avoid duplication and consider -M and -D as convenience
aliases for -m --force and -d --force.

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation/branch: document -d --force and -m --force

The --force option was modified in 356e91f (branch: allow -f with -m and
-d, 2014-12-08), but the documentation was not updated.

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-multimail: update to release 1.1.1

The only change is a bugfix: the SMTP mailer was not working with
Python 2.4.

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

l10n: zh_CN: for git v2.5.0 l10n round 1

Update 65 translations (2355t0f0u) for git v2.5.0-rc0.

Signed-off-by: Jiang Xin <redacted>

index-pack: fix allocation of sorted_by_pos array

When c6458e60 (index-pack: kill union delta_base to save memory,
2015-04-18) attempted to reduce the memory footprint of index-pack,
one of the key thing it did was to keep track of ref-deltas and
ofs-deltas separately.

In fix_unresolved_deltas(), however it forgot that it now wants to
look only at ref deltas in one place.  The code allocated an array
for nr_unresolved, which is sum of number of ref- and ofs-deltas
minus nr_resolved, which may be larger or smaller than the number
ref-deltas.  Depending on nr_resolved, this was either under or over
allocating.

Also, the old code before this change had to use 'i' and 'n' because
some of the things we see in the (old) deltas[] array we scanned
with 'i' would not make it into the sorted_by_pos[] array in the old
world order, but now because you have only ref delta in a separate
ref_deltas[] array, they increment lock&step.  We no longer need
separate variables.  And most importantly, we shouldn't pass the
nr_unresolved parameter, as this number does not play a role in the
working of this helper function.

Helped-by: Nguyễn Thái Ngọc Duy <redacted>
Signed-off-by: Junio C Hamano <redacted>

strbuf: strbuf_read_file() should return ssize_t

It is currently declared to return int, which could overflow for
large files.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

pager: do not leak "GIT_PAGER_IN_USE" to the pager

Since 2e6c012e (setup_pager: set GIT_PAGER_IN_USE, 2011-08-17), we
export GIT_PAGER_IN_USE so that a process that becomes the upstream
of the spawned pager can still tell that we have spawned the pager
and decide to do colored output even when its output no longer goes
to a terminal (i.e. isatty(1)).

But we forgot to clear it from the enviornment of the spawned pager.

This is not a problem in a sane world, but if you have a handful of
thousands Git users in your organization, somebody is bound to do
strange things, e.g. typing "!<ENTER>" instead of 'q' to get control
back from $LESS.  GIT_PAGER_IN_USE is still set in that subshell
spawned by "less", and all sorts of interesting things starts
happening, e.g. "git diff | cat" starts coloring its output.

We can clear the environment variable in the half of the fork that
runs the pager to avoid the confusion.

Signed-off-by: Junio C Hamano <redacted>
Acked-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

l10n: ca.po: update translation

Signed-off-by: Alex Henrie <redacted>

Merge branch 'fr_2.5.0_round1' of git://github.com/jnavila/git

* 'fr_2.5.0_round1' of git://github.com/jnavila/git:
  l10n: fr.po v2.5.0-rc0 (2355t)

Documentation/i18n.txt: clarify character encoding support

As a "distributed" VCS, git should better define the encodings of its core
textual data structures, in particular those that are part of the network
protocol.

That git is encoding agnostic is only really true for blob objects. E.g.
the 'non-NUL bytes' requirement of tree and commit objects excludes
UTF-16/32, and the special meaning of '/' in the index file as well as
space and linefeed in commit objects eliminates EBCDIC and other non-ASCII
encodings.

Git expects bytes < 0x80 to be pure ASCII, thus CJK encodings that partly
overlap with the ASCII range are problematic as well. E.g. fmt_ident()
removes trailing 0x5C from user names on the assumption that it is ASCII
'\'. However, there are over 200 GBK double byte codes that end in 0x5C.

UTF-8 as default encoding on Linux and respective path translations in the
Mac and Windows versions have established UTF-8 NFC as de-facto standard
for path names.

Update the documentation in i18n.txt to reflect the current status-quo.

Signed-off-by: Karsten Blees <redacted>
Signed-off-by: Junio C Hamano <redacted>

Makefile / racy-git.txt: clarify USE_NSEC prerequisites

Signed-off-by: Karsten Blees <redacted>
Signed-off-by: Junio C Hamano <redacted>

Git 2.5.0-rc1

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'me/fetch-into-shallow-safety'

"git fetch --depth=<depth>" and "git clone --depth=<depth>" issued
a shallow transfer request even to an upload-pack that does not
support the capability.

* me/fetch-into-shallow-safety:
  fetch-pack: check for shallow if depth given

Merge branch 'jc/prompt-document-ps1-state-separator'

Docfix.

* jc/prompt-document-ps1-state-separator:
  git-prompt.sh: document GIT_PS1_STATESEPARATOR

Merge branch 'mm/describe-doc'

Docfix.

* mm/describe-doc:
  Documentation/describe: improve one-line summary

Merge branch 'da/mergetool-winmerge'

Hotfix for an earlier change already in 'master' that broke the
default tool selection for mergetool.

* da/mergetool-winmerge:
  mergetool-lib: fix default tool selection

rev-list: disable --use-bitmap-index when pruning commits

The reachability bitmaps do not have enough information to
tell us which commits might have changed path "foo", so the
current code produces wrong answers for:

  git rev-list --use-bitmap-index --count HEAD -- foo

(it silently ignores the "foo" limiter). Instead, we should
fall back to doing a normal traversal (it is OK to fall
back rather than complain, because --use-bitmap-index is a
pure optimization, and might not kick in for other reasons,
such as there being no bitmaps in the repository).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Add tests for wildcard "path vs ref" disambiguation

Commit 28fcc0b (pathspec: avoid the need of "--" when wildcard is used -
2015-05-02) changes how the disambiguation rules work. This patch adds
some tests to demonstrate, basically, if wildcard characters are in an
argument:

 - if the argument is valid extended sha-1 syntax, "--" must be used
 - otherwise the argument is considered a path, even without "--"

And wildcard can appear in extended sha-1 syntax, either as part of
regex in ":/<regex>" or as the literal path in ":<path>". The latter
case is less likely to happen in real world. But if you do ":/" a lot,
you may need to type "--" more.

Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
Signed-off-by: Junio C Hamano <redacted>

fast-import: add a get-mark command

It is sometimes useful for importers to be able to read the SHA-1
corresponding to a mark that they have created via fast-import. For
example, they might want to embed the SHA-1 into the commit message of
a later commit. Or it might be useful for internal bookkeeping uses,
or for logging.

Add a "get-mark" command to "git fast-import" that allows the importer
to ask for the value of a mark that has been created earlier.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Junio C Hamano <redacted>

rev-list: add --count to usage guide

--count should be mentioned in the usage guide, this updates code and
documentation.

Signed-off-by: Lawrence Siebert <redacted>
Signed-off-by: Junio C Hamano <redacted>

l10n: fr.po v2.5.0-rc0 (2355t)

Signed-off-by: Jean-Noel Avila <redacted>
Signed-off-by: Claude Dioudonnat <redacted>

git rebase -i: add static check for commands and SHA-1

Check before the start of the rebasing if the commands exists, and for
the commands expecting a SHA-1, check if the SHA-1 is present and
corresponds to a commit. In case of error, print the error, stop git
rebase and prompt the user to fix with 'git rebase --edit-todo' or to
abort.

This allows to avoid doing half of a rebase before finding an error
and giving back what's left of the todo list to the user and prompt
him to fix when it might be too late for him to do so (he might have
to abort and restart the rebase).

Signed-off-by: Galan Rémi <redacted>
Signed-off-by: Junio C Hamano <redacted>

git rebase -i: warn about removed commits

Check if commits were removed (i.e. a line was deleted) and print
warnings or stop git rebase depending on the value of the
configuration variable rebase.missingCommitsCheck.

This patch gives the user the possibility to avoid silent loss of
information (losing a commit through deleting the line in this case)
if he wants.

Add the configuration variable rebase.missingCommitsCheck.
    - When unset or set to "ignore", no checking is done.
    - When set to "warn", the commits are checked, warnings are
      displayed but git rebase still proceeds.
    - When set to "error", the commits are checked, warnings are
      displayed and the rebase is stopped.
      (The user can then use 'git rebase --edit-todo' and
      'git rebase --continue', or 'git rebase --abort')

rebase.missingCommitsCheck defaults to "ignore".

Signed-off-by: Galan Rémi <redacted>
Signed-off-by: Junio C Hamano <redacted>

git-rebase -i: add command "drop" to remove a commit

Instead of removing a line to remove the commit, you can use the
command "drop" (just like "pick" or "edit"). It has the same effect as
deleting the line (removing the commit) except that you keep a visual
trace of your actions, allowing a better control and reducing the
possibility of removing a commit by mistake.

Signed-off-by: Galan Rémi <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: minor code refactoring

Group expressions in a single if statement. This avoid checking
multiple time if the variable $sender is defined.

Signed-off-by: Remi Lespinet <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: allow use of aliases in the From field of --compose mode

Aliases were expanded before considering the From field of the
--compose option. This is inconsistent with other fields
(To, Cc, ...) which already support aliases.

Signed-off-by: Remi Lespinet <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: refactor address list process

Simplify code by creating a function which transform a list of strings
containing email addresses (separated by commas, comporting aliases)
into a clean list of valid email addresses.

Signed-off-by: Remi Lespinet <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9001-send-email: refactor header variable fields replacement

Create a function which replaces Date, Message-Id and
X-Mailer lines generated by git-send-email by a specific string:

Date:.*$       -> Date: DATE-STRING
Message-Id:.*$ -> Message-Id: MESSAGE-ID-STRING
X-Mailer:.*$   -> X-Mailer: X-MAILER-STRING
Signed-off-by: Remi Lespinet <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

send-email: allow aliases in patch header and command script outputs

Interpret aliases in:

  -  Header fields of patches generated by git format-patch
     (using --to, --cc, --add-header for example) or
     manually modified. Example of fields in header:

      To: alias1
Cc: alias2
Cc: alias3
  -  Outputs of command scripts specified by --cc-cmd and
     --to-cmd. Example of script:

      #!/bin/sh
      echo alias1
      echo alias2

Signed-off-by: Remi Lespinet <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

t9001-send-email: move script creation in a setup test

Move the creation of the scripts used in to-cmd and cc-cmd tests
in a setup test to make them available for later tests.

Signed-off-by: Remi Lespinet <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

status: differentiate interactive from non-interactive rebases

Signed-off-by: Guillaume Pagès <redacted>
Signed-off-by: Junio C Hamano <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

status: factor two rebase-related messages together

Signed-off-by: Guillaume Pagès <redacted>
Signed-off-by: Junio C Hamano <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

config.c: fix writing config files on Windows network shares

Renaming to an existing file doesn't work on Windows network shares if the
target file is open.

munmap() the old config file before commit_lock_file.

Signed-off-by: Karsten Blees <redacted>
Acked-by: Jeff King <redacted>
Acked-by: Johannes Schindelin <redacted>
Signed-off-by: Junio C Hamano <redacted>

bisect: replace hardcoded "bad|good" by variables

To add new tags like old/new and have keywords less confusing, the
first step is to avoid hardcoding the keywords.

The default mode is still bad/good.

Signed-off-by: Antoine Delaite <redacted>
Signed-off-by: Louis Stuber <redacted>
Signed-off-by: Valentin Duperray <redacted>
Signed-off-by: Franck Jonas <redacted>
Signed-off-by: Lucien Kong <redacted>
Signed-off-by: Thomas Nguy <redacted>
Signed-off-by: Huynh Khoi Nguyen Nguyen <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

rebase -i: do not leave a CHERRY_PICK_HEAD file behind

When skipping commits whose changes were already applied via `git rebase
--continue`, we need to clean up said file explicitly.

The same is not true for `git rebase --skip` because that will execute
`git reset --hard` as part of the "skip" handling in git-rebase.sh, even
before git-rebase--interactive.sh is called.

Signed-off-by: Johannes Schindelin <redacted>
Signed-off-by: Junio C Hamano <redacted>

t3404: demonstrate CHERRY_PICK_HEAD bug

When rev-list's --cherry option does not detect that a patch has already
been applied upstream, an interactive rebase would offer to reapply it and
consequently stop at that patch with a failure, mentioning that the diff
is empty.

Traditionally, a `git rebase --continue` simply skips the commit in such a
situation.

However, as pointed out by Gábor Szeder, this leaves a CHERRY_PICK_HEAD
behind, making the Git prompt believe that a cherry pick is still going
on. This commit adds a test case demonstrating this bug.

Signed-off-by: Johannes Schindelin <redacted>
Signed-off-by: Junio C Hamano <redacted>

introduce "format" date-mode

This feeds the format directly to strftime. Besides being a
little more flexible, the main advantage is that your system
strftime may know more about your locale's preferred format
(e.g., how to spell the days of the week).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

convert "enum date_mode" into a struct

In preparation for adding date modes that may carry extra
information beyond the mode itself, this patch converts the
date_mode enum into a struct.

Most of the conversion is fairly straightforward; we pass
the struct as a pointer and dereference the type field where
necessary. Locations that declare a date_mode can use a "{}"
constructor.  However, the tricky case is where we use the
enum labels as constants, like:

  show_date(t, tz, DATE_NORMAL);

Ideally we could say:

  show_date(t, tz, &{ DATE_NORMAL });

but of course C does not allow that. Likewise, we cannot
cast the constant to a struct, because we need to pass an
actual address. Our options are basically:

  1. Manually add a "struct date_mode d = { DATE_NORMAL }"
     definition to each caller, and pass "&d". This makes
     the callers uglier, because they sometimes do not even
     have their own scope (e.g., they are inside a switch
     statement).

  2. Provide a pre-made global "date_normal" struct that can
     be passed by address. We'd also need "date_rfc2822",
     "date_iso8601", and so forth. But at least the ugliness
     is defined in one place.

  3. Provide a wrapper that generates the correct struct on
     the fly. The big downside is that we end up pointing to
     a single global, which makes our wrapper non-reentrant.
     But show_date is already not reentrant, so it does not
     matter.

This patch implements 3, along with a minor macro to keep
the size of the callers sane.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

show-branch: use DATE_RELATIVE instead of magic number

This is more readable, and won't break if we ever change the
order of the date_mode enum.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

http: always use any proxy auth method available

We set CURLOPT_PROXYAUTH to use the most secure authentication
method available only when the user has set configuration variables
to specify a proxy.  However, libcurl also supports specifying a
proxy through environment variables.  In that case libcurl defaults
to only using the Basic proxy authentication method, because we do
not use CURLOPT_PROXYAUTH.

Set CURLOPT_PROXYAUTH to always use the most secure authentication
method available, even when there is no git configuration telling us
to use a proxy. This allows the user to use environment variables to
configure a proxy that requires an authentication method different
from Basic.

Signed-off-by: Enrique A. Tobis <redacted>
Signed-off-by: Junio C Hamano <redacted>

revision.c: remove unneeded check for NULL

The function is called only from one place, which makes sure to have
`interesting_cache` not NULL.  Additionally the variable is a
dereferenced a few lines before unconditionally, which would have
resulted in a segmentation fault before hitting this check.

Signed-off-by: Stefan Beller <redacted>
Acked-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

worktree: new place for "git prune --worktrees"

Commit 23af91d (prune: strategies for linked checkouts - 2014-11-30)
adds "--worktrees" to "git prune" without realizing that "git prune" is
for object database only. This patch moves the same functionality to a
new command "git worktree".

Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>

Merge branch 'master' of git://github.com/alshopov/git-po

* 'master' of git://github.com/alshopov/git-po:
  l10n: Updated Bulgarian translation of git (2355t,0f,0u)

Sync with maint

* maint:

fsck: it is OK for a tag and a commit to lack the body

When fsck validates a commit or a tag, it scans each line in the
header of the object using helper functions such as "start_with()",
etc. that work on a NUL terminated buffer, but before a1e920a0
(index-pack: terminate object buffers with NUL, 2014-12-08), the
validation functions were fed the object data in a piece of memory
that is not necessarily terminated with a NUL.

We added a helper function require_end_of_header() to be called at
the beginning of these validation functions to insist that the
object data contains an empty line before its end.  The theory is
that the validating functions will notice and stop when it hits an
empty line as a normal end of header (or a required header line that
is missing) without scanning past the end of potentially not
NUL-terminated buffer.

But the theory forgot that in the older days, Git itself happily
created objects with only the header lines without a body. This
caused Git 2.2 and later to issue an unnecessary warning in some
existing repositories.

With a1e920a0, we do not need to require an empty line (or the body)
in these objects to safely parse and validate them.  Drop the
offending "must have an empty line" check from this helper function,
while keeping the other check to make sure that there is no NUL in
the header part of the object, and adjust the name of the helper to
what it does accordingly.

Noticed-by: Wolfgang Denk <redacted>
Helped-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

rerere: fix an off-by-one non-bug

When ac49f5ca (rerere "remaining", 2011-02-16) split out a new
helper function check_one_conflict() out of find_conflict()
function, so that the latter will use the returned value from the
new helper to update the loop control variable that is an index into
active_cache[], the new variable incremented the index by one too
many when it found a path with only stage #1 entry at the very end
of active_cache[].

This "strange" return value does not have any effect on the loop
control of two callers of this function, as they all notice that
active_nr+2 is larger than active_nr just like active_nr+1 is, but
nevertheless it puzzles the readers when they are trying to figure
out what the function is trying to do.

In fact, there is no need to do an early return.  The code that
follows after skipping the stage #1 entry is fully prepared to
handle a case where the entry is at the very end of active_cache[].

Help future readers from unnecessary confusion by dropping an early
return.  We skip the stage #1 entry, and if there are stage #2 and
stage #3 entries for the same path, we diagnose the path as
THREE_STAGED (otherwise we say PUNTED), and then we skip all entries
for the same path.

Signed-off-by: Junio C Hamano <redacted>

l10n: Updated Bulgarian translation of git (2355t,0f,0u)

Signed-off-by: Alexander Shopov <redacted>

l10n: sv.po: Update Swedish translation (2355t0f0u)

Signed-off-by: Peter Krefting <redacted>

l10n: Updated Vietnamese translation (2355t)

Signed-off-by: Tran Ngoc Quan <redacted>

l10n: git.pot: v2.5.0 round 1 (65 new, 15 removed)

Generate po/git.pot from v2.5.0-rc0 for git v2.5.0 l10n round 1.

Signed-off-by: Jiang Xin <redacted>

p5310: Fix broken && chain in performance test

Signed-off-by: Stefan Beller <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation/bisect: revise overall content

Thoroughly revise the "git bisect" manpage, including:

* Beef up the "Description" section.

* Make the first long example less specific to kernel development.

* De-emphasize implementation details in a couple of places.

* Add "(roughly N steps)" in the places where example output is shown.

* Properly markup code within the prose.

* Lots of wordsmithing.

Signed-off-by: Michael Haggerty <redacted>
Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR

In the test case, we run setup_git_dir_gently() the first time to read
$GIT_DIR/config so that we can resolve aliases. We'll enter
setup_discovered_git_dir() and may or may not call set_git_dir() near
the end of the function, depending on whether the detected git dir is
".git" or not. This set_git_dir() will set env var $GIT_DIR.

For normal repo, git dir detected via setup_discovered_git_dir() will be
".git", and set_git_dir() is not called. If .git file is used however,
the git dir can't be ".git" and set_git_dir() is called and $GIT_DIR
set. This is the key of this problem.

If we expand an alias (or autocorrect command names), then
setup_git_dir_gently() is run the second time. If $GIT_DIR is not set in
the first run, we run the same setup_discovered_git_dir() as before.
Nothing to see. If it is, however, we'll enter setup_explicit_git_dir()
this time.

This is where the "fun" is.  If $GIT_WORK_TREE is not set but
$GIT_DIR is, you are supposed to be at the root level of the
worktree.  But if you are in a subdir "foo/bar" (real worktree's top
is "foo"), this rule bites you: your detected worktree is now
"foo/bar", even though the first run correctly detected worktree as
"foo". You get "internal error: work tree has already been set" as a
result.

Bottom line is, when $GIT_DIR is set, $GIT_WORK_TREE should be set too
unless there's no work tree. But setting $GIT_WORK_TREE inside
set_git_dir() may backfire. We don't know at that point if work tree is
already configured by the caller. So set it when work tree is
detected. It does not harm if $GIT_WORK_TREE is set while $GIT_DIR is
not.

Reported-by: Bjørnar Snoksrud <redacted>
Signed-off-by: Nguyễn Thái Ngọc Duy <redacted>
Signed-off-by: Junio C Hamano <redacted>

Documentation/bisect: move getting help section to the end

Signed-off-by: Matthieu Moy <redacted>
Signed-off-by: Junio C Hamano <redacted>

cat-file: sort and de-dup output of --batch-all-objects

The sorting we could probably live without, but printing
duplicates is just a hassle for the user, who must then
de-dup themselves (or risk a wrong answer if they are doing
something like counting objects with a particular property).

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

read_gitfile_gently: fix use-after-free

The "dir" variable is a pointer into the "buf" array. When
we hit the cleanup_return path, the first thing we do is
free(buf); but one of the error messages prints "dir", which
will access the memory after the free.

We can fix this by reorganizing the error path a little. We
act on the fatal, error-printing conditions first, as they
want to access memory and do not care about freeing. Then we
free any memory, and finally return.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Merge branch 'jk/stash-require-clean-index' into maint

A hotfix for the topic already in 'master'.

* jk/stash-require-clean-index:
  Revert "stash: require a clean index to apply"

Merge branch 'cb/array-size' into maint

* cb/array-size:
  Fix definition of ARRAY_SIZE for non-gcc builds

Git 2.5.0-rc0

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'cn/cvsimport-perl-update'

* cn/cvsimport-perl-update:
  cvsimport: silence regex warning appearing in Perl 5.22.

Merge branch 'cb/array-size'

* cb/array-size:
  Fix definition of ARRAY_SIZE for non-gcc builds

Sync with 2.4.5

Git 2.4.5

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'sg/merge-summary-config' into maint

Doc updates.

* sg/merge-summary-config:
  Documentation: include 'merge.branchdesc' for merge and config as well

Merge branch 'jk/make-fix-dependencies' into maint

Build clean-up.

* jk/make-fix-dependencies:
  Makefile: silence perl/PM.stamp recipe
  Makefile: avoid timestamp updates to GIT-BUILD-OPTIONS
  Makefile: drop dependency between git-instaweb and gitweb

Merge branch 'sb/pack-protocol-mention-smart-http' into maint

Doc updates.

* sb/pack-protocol-mention-smart-http:
  Documentation/technical/pack-protocol: mention http as possible protocol

Merge branch 'jk/die-on-bogus-worktree-late' into maint

The setup code used to die when core.bare and core.worktree are set
inconsistently, even for commands that do not need working tree.

* jk/die-on-bogus-worktree-late:
  setup_git_directory: delay core.bare/core.worktree errors

Merge branch 'pt/pull-tags-error-diag' into maint

There was a dead code that used to handle "git pull --tags" and
show special-cased error message, which was made irrelevant when
the semantics of the option changed back in Git 1.9 days.

* pt/pull-tags-error-diag:
  pull: remove --tags error in no merge candidates case

Merge branch 'jk/color-diff-plain-is-context' into maint

"color.diff.plain" was a misnomer; give it 'color.diff.context' as
a more logical synonym.

* jk/color-diff-plain-is-context:
  diff.h: rename DIFF_PLAIN color slot to DIFF_CONTEXT
  diff: accept color.diff.context as a synonym for "plain"

Merge branch 'jk/diagnose-config-mmap-failure' into maint

The configuration reader/writer uses mmap(2) interface to access
the files; when we find a directory, it barfed with "Out of memory?".

* jk/diagnose-config-mmap-failure:
  xmmap(): drop "Out of memory?"
  config.c: rewrite ENODEV into EISDIR when mmap fails
  config.c: avoid xmmap error messages
  config.c: fix mmap leak when writing config
  read-cache.c: drop PROT_WRITE from mmap of index

Merge branch 'jk/squelch-missing-link-warning-for-unreachable' into maint

Recent "git prune" traverses young unreachable objects to safekeep
old objects in the reachability chain from them, which sometimes
caused error messages that are unnecessarily alarming.

* jk/squelch-missing-link-warning-for-unreachable:
  suppress errors on missing UNINTERESTING links
  silence broken link warnings with revs->ignore_missing_links
  add quieter versions of parse_{tree,commit}

Merge branch 'mm/rebase-i-post-rewrite-exec' into maint

"git rebase -i" fired post-rewrite hook when it shouldn't (namely,
when it was told to stop sequencing with 'exec' insn).

* mm/rebase-i-post-rewrite-exec:
  t5407: use <<- to align the expected output
  rebase -i: fix post-rewrite hook with failed exec command
  rebase -i: demonstrate incorrect behavior of post-rewrite

Merge branch 'nd/diff-i-t-a'

* nd/diff-i-t-a:
  Revert "diff-lib.c: adjust position of i-t-a entries in diff"

cvsimport: silence regex warning appearing in Perl 5.22.

Since Perl 5.22, "A literal '{' should now be escaped in a pattern".
Silence the recently added warning by using \{ instead.

Signed-off-by: Christian Neukirchen <redacted>
Signed-off-by: Junio C Hamano <redacted>

Fix definition of ARRAY_SIZE for non-gcc builds

The improved ARRAY_SIZE macro uses BARF_UNLESS_AN_ARRAY which expands
to a valid check for recent gcc versions and to 0 for older gcc
versions but is not defined on non-gcc builds.

Non-gcc builds need this macro to expand to 0 as well. The current outer
test (defined(__GNUC__) && (__GNUC__ >= 3)) is a strictly weaker
condition than the inner test (GIT_GNUC_PREREQ(3, 1)) so we can omit the
outer test and cause the BARF_UNLESS_AN_ARRAY macro to be defined
correctly on non-gcc builds as well as gcc builds with older versions.

Signed-off-by: Charles Bailey <redacted>
Signed-off-by: Junio C Hamano <redacted>

introduce "preciousObjects" repository extension

If this extension is used in a repository, then no
operations should run which may drop objects from the object
storage. This can be useful if you are sharing that storage
with other repositories whose refs you cannot see.

For instance, if you do:

  $ git clone -s parent child
  $ git -C parent config extensions.preciousObjects true
  $ git -C parent config core.repositoryformatversion 1

you now have additional safety when running git in the
parent repository. Prunes and repacks will bail with an
error, and `git gc` will skip those operations (it will
continue to pack refs and do other non-object operations).
Older versions of git, when run in the repository, will
fail on every operation.

Note that we do not set the preciousObjects extension by
default when doing a "clone -s", as doing so breaks
backwards compatibility. It is a decision the user should
make explicitly.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

introduce "extensions" form of core.repositoryformatversion

Normally we try to avoid bumps of the whole-repository
core.repositoryformatversion field. However, it is
unavoidable if we want to safely change certain aspects of
git in a backwards-incompatible way (e.g., modifying the set
of ref tips that we must traverse to generate a list of
unreachable, safe-to-prune objects).

If we were to bump the repository version for every such
change, then any implementation understanding version `X`
would also have to understand `X-1`, `X-2`, and so forth,
even though the incompatibilities may be in orthogonal parts
of the system, and there is otherwise no reason we cannot
implement one without the other (or more importantly, that
the user cannot choose to use one feature without the other,
weighing the tradeoff in compatibility only for that
particular feature).

This patch documents the existing repositoryformatversion
strategy and introduces a new format, "1", which lets a
repository specify that it must run with an arbitrary set of
extensions. This can be used, for example:

 - to inform git that the objects should not be pruned based
   only on the reachability of the ref tips (e.g, because it
   has "clone --shared" children)

 - that the refs are stored in a format besides the usual
   "refs" and "packed-refs" directories

Because we bump to format "1", and because format "1"
requires that a running git knows about any extensions
mentioned, we know that older versions of the code will not
do something dangerous when confronted with these new
formats.

For example, if the user chooses to use database storage for
refs, they may set the "extensions.refbackend" config to
"db". Older versions of git will not understand format "1"
and bail. Versions of git which understand "1" but do not
know about "refbackend", or which know about "refbackend"
but not about the "db" backend, will refuse to run. This is
annoying, of course, but much better than the alternative of
claiming that there are no refs in the repository, or
writing to a location that other implementations will not
read.

Note that we are only defining the rules for format 1 here.
We do not ever write format 1 ourselves; it is a tool that
is meant to be used by users and future extensions to
provide safety with older implementations.

Signed-off-by: Jeff King <redacted>
Signed-off-by: Junio C Hamano <redacted>

Ninth batch for 2.5

Signed-off-by: Junio C Hamano <redacted>

Merge branch 'jk/stash-require-clean-index'

A hotfix for the topic already in 'master'.

* jk/stash-require-clean-index:
  Revert "stash: require a clean index to apply"

Merge branch 'pa/auto-gc-mac-osx'

Recent Mac OS X updates breaks the logic to detect that the machine
is on the AC power in the sample pre-auto-gc script.

* pa/auto-gc-mac-osx:
  hooks/pre-auto-gc: adjust power checking for newer OS X

Merge branch 'pt/t0302-needs-sanity'

* pt/t0302-needs-sanity:
  t0302: "unreadable" test needs SANITY prereq

Merge branch 'ld/p4-changes-block-size'

More Perforce row number limit workaround for "git p4".

* ld/p4-changes-block-size:
  git-p4: fixing --changes-block-size handling
  git-p4: add tests for non-numeric revision range
  git-p4: test with limited p4 server results
  git-p4: additional testing of --changes-block-size

Merge branch 'fk/doc-format-patch-vn'

Docfix.

* fk/doc-format-patch-vn:
  doc: format-patch: fix typo

Merge branch 'sg/commit-cleanup-scissors'

"git commit --cleanup=scissors" was not careful enough to protect
against getting fooled by a line that looked like scissors.

* sg/commit-cleanup-scissors:
  commit: cope with scissors lines in commit message

Merge branch 'jk/index-pack-reduce-recheck'

Disable "have we lost a race with competing repack?" check while
receiving a huge object transfer that runs index-pack.

* jk/index-pack-reduce-recheck:
  index-pack: avoid excessive re-reading of pack directory

Merge branch 'af/tcsh-completion-noclobber'

The tcsh completion writes a bash scriptlet but that would have
failed for users with noclobber set.

* af/tcsh-completion-noclobber:
  git-completion.tcsh: fix redirect with noclobber

Merge branch 'mh/reporting-broken-refs-from-for-each-ref'

"git for-each-ref" reported "missing object" for 0{40} when it
encounters a broken ref.  The lack of object whose name is 0{40} is
not the problem; the ref being broken is.

* mh/reporting-broken-refs-from-for-each-ref:
  read_loose_refs(): treat NULL_SHA1 loose references as broken
  read_loose_refs(): simplify function logic
  for-each-ref: report broken references correctly
  t6301: new tests of for-each-ref error handling

Merge branch 'sg/completion-commit-cleanup'

* sg/completion-commit-cleanup:
  completion: teach 'scissors' mode to 'git commit --cleanup='

Merge branch 'pt/am-abort-fix'

Various fixes around "git am" that applies a patch to a history
that is not there yet.

* pt/am-abort-fix:
  am --abort: keep unrelated commits on unborn branch
  am --abort: support aborting to unborn branch
  am --abort: revert changes introduced by failed 3way merge
  am --skip: support skipping while on unborn branch
  am -3: support 3way merge on unborn branch
  am --skip: revert changes introduced by failed 3way merge

Merge branch 'nd/untracked-cache'

Hotfix for the 'untracked-cache' topic that is already in 'master'.

* nd/untracked-cache:
  read-cache: fix untracked cache invalidation when split-index is used

Merge branch 'mh/fsck-reflog-entries'

"git fsck" used to ignore missing or invalid objects recorded in reflog.

* mh/fsck-reflog-entries:
  fsck: report errors if reflog entries point at invalid objects
  fsck_handle_reflog_sha1(): new function

Merge branch 'js/sleep-without-select'

Portability fix.

* js/sleep-without-select:
  lockfile: wait using sleep_millisec() instead of select()
  lockfile: convert retry timeout computations to millisecond
  help.c: wrap wait-only poll() invocation in sleep_millisec()
  lockfile: replace random() by rand()

Merge branch 'es/utf8-stupid-compiler-workaround'

A compilation workaround.

* es/utf8-stupid-compiler-workaround:
  utf8: NO_ICONV: silence uninitialized variable warning

Merge branch 'rl/am-3way-config'

"git am" learned am.threeWay configuration variable.

* rl/am-3way-config:
  git-am: add am.threeWay config variable
  t4150-am: refactor am -3 tests
  git-am.sh: fix initialization of the threeway variable

Merge branch 'jc/ll-merge-expose-path'

Traditionally, external low-level 3-way merge drivers are expected
to produce their results based solely on the contents of the three
variants given in temporary files named by %O, %A and %B on their
command line.  Additionally allow them to look at the final path
(given by %P).

* jc/ll-merge-expose-path:
  ll-merge: pass the original path to external drivers

Merge branch 'es/osx-header-pollutes-mask-macro'

* es/osx-header-pollutes-mask-macro:
  ewah: use less generic macro name
  ewah/bitmap: silence warning about MASK macro redefinition

Merge branch 'es/configure-getdelim'

Auto-detect availability of getdelim() that helps optimized version
of strbuf_getwholeline().

* es/configure-getdelim:
  configure: add getdelim() check
  config.mak.uname: Darwin: define HAVE_GETDELIM for modern OS X releases

Merge branch 'pt/pull-optparse'

"git pull" has become more aware of the options meant for
underlying "git fetch" and then learned to use parse-options
parser.

* pt/pull-optparse:
  pull: use git-rev-parse --parseopt for option parsing
  pull: handle git-fetch's options as well