t0027: check the eol conversion warnings

Depending on the file content, eol parameters and .gitattributes
"git add" may give a warning when the eol of a file will change when
the file is checked out again.

There are 2 different warnings, either "CRLF will be replaced..." or
"LF will be replaced...".  Let t0027 check for these warnings by
adding new parameters to create_file_in_repo(), which tells what
warnings are expected.

When a file has eol=lf or eol=crlf in .gitattributes, it is handled
as text and should be normalized.  Add tests for these cases that
were not covered.

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

First batch for 2.3 cycle

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

Merge branch 'mh/config-flip-xbit-back-after-checking'

* mh/config-flip-xbit-back-after-checking:
  create_default_files(): don't set u+x bit on $GIT_DIR/config

Merge branch 'jk/gitweb-with-newer-cgi-multi-param'

* jk/gitweb-with-newer-cgi-multi-param:
  gitweb: hack around CGI's list-context param() handling

Merge branch 'rs/receive-pack-use-labs'

* rs/receive-pack-use-labs:
  use labs() for variables of type long instead of abs()

Merge branch 'rs/maint-config-use-labs'

* rs/maint-config-use-labs:
  use labs() for variables of type long instead of abs()

Merge branch 'js/windows-open-eisdir-error'

* js/windows-open-eisdir-error:
  Windows: correct detection of EISDIR in mingw_open()

Merge branch 'jh/empty-notes'

A request to store an empty note via "git notes" meant to remove
note from the object but with --allow-empty we will store a (surprise!)
note that is empty.  In the longer run, we might want to deprecate
the somewhat unintuitive "emptying means deletion" behaviour.

* jh/empty-notes:
  t3301: modernize style
  notes: empty notes should be shown by 'git log'
  builtin/notes: add --allow-empty, to allow storing empty notes
  builtin/notes: split create_note() to clarify add vs. remove logic
  builtin/notes: simplify early exit code in add()
  builtin/notes: refactor note file path into struct note_data
  builtin/notes: improve naming
  t3301: verify that 'git notes' removes empty notes by default
  builtin/notes: fix premature failure when trying to add the empty blob

Merge branch 'sv/get-builtin'

* sv/get-builtin:
  builtin: move builtin retrieval to get_builtin()

Merge branch 'jk/checkout-from-tree'

"git checkout $treeish $path", when $path in the index and the
working tree already matched what is in $treeish at the $path,
still overwrote the $path unnecessarily.

* jk/checkout-from-tree:
  checkout $tree: do not throw away unchanged index entries

Merge branch 'tq/git-ssh-command'

Allow passing extra set of arguments when ssh is invoked to create
an encrypted & authenticated connection by introducing a new environment
variable GIT_SSH_COMMAND, whose contents is interpreted by shells.

This is not possible with existing GIT_SSH mechanism whose
invocation bypasses shells, which was designed more to match what
other programs with similar variables did, not necessarily to be
more useful.

* tq/git-ssh-command:
  git_connect: set ssh shell command in GIT_SSH_COMMAND

Merge branch 'rs/env-array-in-child-process'

* rs/env-array-in-child-process:
  use args member of struct child_process

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

* 'maint' of git://github.com/git-l10n/git-po:
  l10n: de.po: fix typos

Start post 2.2 cycle

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

for_each_reflog_ent_reverse: turn leftover check into assertion

Our loop should always process all lines, even if we hit the
beginning of the file. We have a conditional after the loop
ends to double-check that there is nothing left and to
process it. But this should never happen, and is a sign of a
logic bug in the loop. Let's turn it into a BUG assertion.

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

for_each_reflog_ent_reverse: fix newlines on block boundaries

When we read a reflog file in reverse, we read whole chunks
of BUFSIZ bytes, then loop over the buffer, parsing any
lines we find. We find the beginning of each line by looking
for the newline from the previous line. If we don't find
one, we know that we are either at the beginning of
the file, or that we have to read another block.

In the latter case, we stuff away what we have into a
strbuf, read another block, and continue our parse. But we
missed one case here. If we did find a newline, and it is at
the beginning of the block, we must also stuff that newline
into the strbuf, as it belongs to the block we are about to
read.

The minimal fix here would be to add this special case to
the conditional that checks whether we found a newline.
But we can make the flow a little clearer by rearranging a
bit: we first handle lines that we are going to show, and
then at the end of each loop, stuff away any leftovers if
necessary. That lets us fold this special-case in with the
more common "we ended in the middle of a line" case.

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

string_list: remove string_list_insert_at_index() from its API

There no longer is a caller to this function.

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

mailmap: use higher level string list functions

No functional changes intended. This commit makes use of higher level
and better documented functions of the string list API, so the code is
more understandable.

Note that also the required computational amount should not change
in principal as we need to look up the item no matter if it is already
part of the list or not. Once looked up, insertion comes for free.

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

Documentation/git-stripspace: add synopsis for --comment-lines

Signed-off-by: Slavomir Vlcek <svlc@inventati.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

check-ignore: clarify treatment of tracked files

By default, check-ignore does not list tracked files at all since
they are not subject to ignore patterns.

Make this clearer in the man page.

Reported-by: Guilherme <guibufolo@gmail.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3200-branch: test -M

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

completion: add git-tag options

Add completion for git-tag options including
all options that are currently shown in "git tag -h".

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

compat: convert modes to use portable file type values

This adds simple wrapper functions around calls to stat(), fstat(),
and lstat() that translate the operating system's native file type
bits to those used by most operating systems.  It also rewrites the
S_IF* macros to the common values, so all file type processing is
performed using the translated modes.  This makes projects portable
across operating systems that use different file type definitions.

Only the file type bits may be affected by these compatibility
functions; the file permission bits are assumed to be 07777 and are
passed through unchanged.

Signed-off-by: David Michael <fedora.dm0@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

prompt: respect GIT_TERMINAL_PROMPT to disable terminal prompts

If you run git as part of an automated system, you might
prefer git to die rather than try to issue a prompt on the
terminal (because there would be nobody to see it and
respond, and the process would hang forever).

This usually works out of the box because getpass() (and our
more featureful replacements) will fail when there is no
tty, but this does not cover all cases. For example, a batch
system run via ssh might have a tty, even when the user does
not expect it.

Let's provide an environment variable the user can set to
avoid even trying to touch the tty at all.

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

credential: let helpers tell us to quit

When we are trying to fill a credential, we loop over the
set of defined credential-helpers, then fall back to running
askpass, and then finally prompt on the terminal. Helpers
which cannot find a credential are free to tell us nothing,
but they cannot currently ask us to stop prompting.

This patch lets them provide a "quit" attribute, which asks
us to stop the process entirely (avoiding running more
helpers, as well as the askpass/terminal prompt).

This has a few possible uses:

  1. A helper which prompts the user itself (e.g., in a
     dialog) can provide a "cancel" button to the user to
     stop further prompts.

  2. Some helpers may know that prompting cannot possibly
     work. For example, if their role is to broker a ticket
     from an external auth system and that auth system
     cannot be contacted, there is no point in continuing
     (we need a ticket to authenticate, and the user cannot
     provide one by typing it in).

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

git-new-workdir: don't fail if the target directory is empty

Allow new workdirs to be created in an empty directory (similar to "git
clone").  Provide more error checking and clean up on failure.

Signed-off-by: Paul Smith <paul@mad-scientist.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t3102: style modernization

Use <<-\END_OF_HERE_DOCUMENT to allow indenting the HERE document to
make it clear where each test begins and ends, and relieve readers
from having to worry about variable substitution.

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

t3102: document that ls-tree does not yet support negated pathspec

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

ls-tree: disable negative pathspec because it's not supported

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

ls-tree: remove path filtering logic in show_tree

ls-tree uses read_tree_recursive() which already does path filtering
using pathspec. No need to filter one more time based on prefix
only. "ls-tree ../somewhere" does not work because of
this. write_name_quotedpfx() can now be retired because nobody else
uses it.

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

tree.c: update read_tree_recursive callback to pass strbuf as base

This allows the callback to use 'base' as a temporary buffer to
quickly assemble full path "without" extra allocation. The callback
has to restore it afterwards of course.

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

run-command.c: retire unused run_hook_with_custom_index()

This was originally meant to be used to rewrite run_commit_hook()
that only special cases the GIT_INDEX_FILE environment, but the
run_hook_ve() refactoring done earlier made the implementation of
run_commit_hook() thin and clean enough.

Nobody uses this, so retire it as an unfinished clean-up made
unnecessary.

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

for-each-ref: correct spelling of Tcl in option description

Tcl is conventionally spelled "Tcl". The description of
option "--tcl", however, spells it "tcl". Let's follow
the convention.

Reported-by: Hartmut Henkel <hartmut_henkel@gmx.de>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0050-*.sh: mark the rename (case change) test as passing

Since commit baa37bff ("mv: allow renaming to fix case on case
insensitive filesystems", 08-05-2014), the 'git mv' command has
been able to rename a file, to one which differs only in case,
on a case insensitive filesystem.

This results in the 'rename (case change)' test, which used to fail
prior to this commit, to now (unexpectedly) pass. Mark this test as
passing.

[jc: Ramsay's tests on Cygwin, Eric's on Mac OS X]

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

push: truly use "simple" as default, not "upstream"

The plan for the push.default transition had all along been
to use the "simple" method rather than "upstream" as a
default if the user did not specify their own push.default
value. Commit 11037ee (push: switch default from "matching"
to "simple", 2013-01-04) tried to implement that by moving
PUSH_DEFAULT_UNSPECIFIED in our switch statement to
fall-through to the PUSH_DEFAULT_SIMPLE case.

When the commit that became 11037ee was originally written,
that would have been enough. We would fall through to
calling setup_push_upstream() with the "simple" parameter
set to 1. However, it was delayed for a while until we were
ready to make the transition in Git 2.0.

And in the meantime, commit ed2b182 (push: change `simple`
to accommodate triangular workflows, 2013-06-19) threw a
monkey wrench into the works. That commit drops the "simple"
parameter to setup_push_upstream, and instead checks whether
the global "push_default" is PUSH_DEFAULT_SIMPLE. This is
right when the user has explicitly configured push.default
to simple, but wrong when we are a fall-through for the
"unspecified" case.

We never noticed because our push.default tests do not cover
the case of the variable being totally unset; they only
check the "simple" behavior itself.

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

pack-bitmap: do not use gcc packed attribute

The "__attribute__" flag may be a noop on some compilers.
That's OK as long as the code is correct without the
attribute, but in this case it is not. We would typically
end up with a struct that is 2 bytes too long due to struct
padding, breaking both reading and writing of bitmaps.

Instead of marshalling the data in a struct, let's just
provide helpers for reading and writing the appropriate
types. Besides being correct on all platforms, the result is
more efficient and simpler to read.

Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t5516: more tests for receive.denyCurrentBranch=updateInstead

The previous one tests only the case where a path to be updated by
the push-to-deploy has an incompatible change in the target's
working tree that has already been added to the index, but the
feature itself wants to require the working tree to be a lot cleaner
than what is tested.  Add a handful more tests to protect the
feature from future changes that mistakenly (from the viewpoint of
the inventor of the feature) loosens the cleanliness requirement,
namely:

 - A change only to the working tree but not to the index is still a
   change to be protected;

 - An untracked file in the working tree that would be overwritten
   by a push-to-deploy needs to be protected;

 - A change that happens to make a file identical to what is being
   pushed is still a change to be protected (i.e. the feature's
   cleanliness requirement is more strict than that of checkout).

Also, test that a stat-only change to the working tree is not a
reason to reject a push-to-deploy.

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

receive-pack: add another option for receive.denyCurrentBranch

When synchronizing between working directories, it can be handy to update
the current branch via 'push' rather than 'pull', e.g. when pushing a fix
from inside a VM, or when pushing a fix made on a user's machine (where
the developer is not at liberty to install an ssh daemon let alone know
the user's password).

The common workaround – pushing into a temporary branch and then merging
on the other machine – is no longer necessary with this patch.

The new option is:

'updateInstead':
Update the working tree accordingly, but refuse to do so if there
are any uncommitted changes.

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

system_path(): always return free'able memory to the caller

The function sometimes returns a newly allocated string and
sometimes returns a borrowed string, the latter of which the callers
must not free().  The existing callers all assume that the return
value belongs to the callee and most of them copy it with strdup()
when they want to keep it around.  They end up leaking the returned
copy when the callee returned a new string because they cannot tell
if they should free it.

Change the contract between the callers and system_path() to make
the returned string owned by the callers; they are responsible for
freeing it when done, but they do not have to make their own copy to
store it away.

Adjust the callers to make sure they do not leak the returned string
once they are done, but do not bother freeing it just before dying,
exiting or exec'ing other program to avoid unnecessary churn.

Reported-by: Alexander Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'master' of https://github.com/ralfth/git-po-de

* 'master' of https://github.com/ralfth/git-po-de:
  l10n: de.po: fix typos

l10n: de.po: fix typos

Signed-off-by: Hartmut Henkel <hartmut_henkel@gmx.de>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>

Git 2.2

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

RelNotes: spelling & grammar tweaks

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sha1_name: avoid unnecessary sha1 lookup in find_unique_abbrev

An example where this happens is when doing an ls-tree on a tree that
contains a commit link. In that case, find_unique_abbrev is called
to get a non-abbreviated hex sha1, but still, a lookup is done as
to whether the sha1 is in the repository (which ends up looking for
a loose object in .git/objects), while the result of that lookup is
not used when returning a non-abbreviated hex sha1.

Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-am: add --message-id/--no-message-id

Parse the option and pass it directly to git-mailinfo.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-mailinfo: add --message-id

This option adds the content of the Message-Id header at the end of the
commit message prepared by git-mailinfo.  This is useful in order to
associate commit messages automatically with mailing list discussions.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9001: style modernisation phase #5

Two general shell script codingstyles around here-text.

 - Quote the <<\END_OF_HERE_TEXT string when there is no parameter
   substitution going on to reduce cognitive load of the reader.

 - Indent the text with <<-\END_OF_HERE_TEXT when able to make it
   easier to spot boundaries of the tests.

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

t9001: style modernisation phase #4

Two general shell script codingstyles.

 - No SP between redirection operator and its target
 - One SP on both sides of () in "name () {" that begins a shell function

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

t9001: style modernisation phase #3

Use write_script.  The resulting patch makes it a lot easier
to understand what the written script is doing.

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

t9001: style modernisation phase #2

Indent is done with HTs, not a run of SPs.

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

t9001: style modernisation phase #1

Don't chop test_expect_success line into pieces and concatenate with
'\'.  That's so 2005.

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

git-send-email: add --transfer-encoding option

The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392
details problems when applying patches with "git am" in a repository with
CRLF line endings.  In the example in the thread, the repository originated
from "git-svn" so it is not possible to use core.eol and friends on it.

Right now, the best option is to use "git am --keep-cr".  However, when
a patch create new files, the patch application process will reject the
new file because it finds a "/dev/null\r" string instead of "/dev/null".

The problem is that SMTP transport is CRLF-unsafe.  Sending a patch by
email is the same as passing it through "dos2unix | unix2dos".  The newly
introduced CRLFs are normally transparent because git-am strips them. The
keepcr=true setting preserves them, but it is mostly working by chance
and it would be very problematic to have a "git am" workflow in a
repository with mixed LF and CRLF line endings.

The MIME solution to this is the quoted-printable transfer enconding.
This is not something that we want to enable by default, since it makes
received emails horrible to look at.  However, it is a very good match
for projects that store CRLF line endings in the repository.

The only disadvantage of quoted-printable is that quoted-printable
patches fail to apply if the maintainer uses "git am --keep-cr".  This
is because the decoded patch will have two carriage returns at the end
of the line.  Therefore, add support for base64 transfer encoding too,
which makes received emails downright impossible to look at outside
a MUA, but really just works.

The patch covers all bases, including users that still live in the late
80s, by also providing a 7bit content transfer encoding that refuses
to send emails with non-ASCII character in them.  And finally, "8bit"
will add a Content-Transfer-Encoding header but otherwise do nothing.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-send-email: delay creation of MIME headers

After the next patch, git-send-email will sometimes modify
existing Content-Transfer-Encoding headers.  Delay the addition
of the header to @xh until just before sending.  Do the same
for MIME-Version, to avoid adding it twice.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

sort_string_list(): rename to string_list_sort()

The new name is more consistent with the names of other
string_list-related functions.

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

prune_remote(): iterate using for_each_string_list_item()

Iterate over refs_to_prune using for_each_string_list_item() rather
than writing out the loop in longhand.

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

prune_remote(): rename local variable

Rename "delete_refs_list" to "refs_to_prune". The new name is more
self-explanatory.

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

repack_without_refs(): make the refnames argument a string_list

Most of the callers have string_lists available already, whereas two
of them had to read data out of a string_list into an array of strings
just to call this function. So change repack_without_refs() to take
the list of refnames to omit as a string_list, and change the callers
accordingly.

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

prune_remote(): sort delete_refs_list references en masse

Inserting items into a list in sorted order is O(N^2) whereas
appending them unsorted and then sorting the list all at once is
O(N lg N).

string_list_insert() also removes duplicates, and this change loses
that functionality. But the strings in this list, which ultimately
come from a for_each_ref() iteration, cannot contain duplicates.

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

prune_remote(): initialize both delete_refs lists in a single loop

Also free them together at the end of the function.

In a moment, the array version will become redundant. Managing them
together makes later steps more obvious.

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

prune_remote(): exit early if there are no stale references

Aside from making the logic clearer, this avoids a call to
warn_dangling_symrefs(), which always does a for_each_rawref()
iteration.

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

git-sh-setup.sh: use dashdash with basename call

Calling basename on a argument that starts with a dash, like a login
shell, will result in an error. Add '--' before the argument so that
the argument is interpreted properly.

Signed-off-by: Dan Wyand <danwyand@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

string_list: document string_list_(insert,lookup)

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

git-compat-util.h: don't define _XOPEN_SOURCE on cygwin

A recent update to the gcc compiler (v4.8.3-5 x86_64) on 64-bit
cygwin leads to several new warnings about the implicit declaration
of the memmem(), strlcpy() and strcasestr() functions. For example:

  CC archive.o
  archive.c: In function 'format_subst':
  archive.c:44:3: warning: implicit declaration of function 'memmem' \
    [-Wimplicit-function-declaration]
     b = memmem(src, len, "$Format:", 8);
       ^
  archive.c:44:5: warning: assignment makes pointer from integer \
    without a cast [enabled by default]
     b = memmem(src, len, "$Format:", 8);
       ^

This is because <string.h> on Cygwin used to always declare the
above functions, but a recent version of it no longer make them
visible when _XOPEN_SOURCE is set (even if _GNU_SOURCE and
_BSD_SOURCE is set).

In order to suppress the warnings, don't define the _XOPEN_SOURCE
macro on cygwin.

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

t5000 on Windows: do not mistake "sh.exe" as "sh"

In their effort to emulate POSIX as close as possible, the MSYS tools
and Cygwin treat the file name "foo.exe" as "foo" when the latter is
asked for, but not present, but the former is present.

Following this rule, 'cp /bin/sh a/bin' actually copies the file
/bin/sh.exe, so that we now have a/bin/sh.exe in the repository. This
difference did not matter in the tests in the past because we were only
interested in the equality of contents generated in various ways. But
recently added tests check file names, in particular, the presence of
"a/bin/sh". This test fails on Windows, as we do not have a file by this
name, but "a/bin/sh.exe".

Use test-genrandom to generate the large binary file in the repository
under the expected name.

We could change the guilty line to 'cat /bin/sh >a/bin/sh', but it is
better for test reproducibility to ensure that the test data is the same
across platforms, which test-genrandom can guarantee.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t/README: justify why "! grep foo" is sufficient

We require use of test_must_fail to check expected non-zero exit by
Git itself, but discourage test_must_fail to be used for checking
exit status of non Git commands that are supplied by the system.
The current text explains the reason for the former but not the
latter.

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

SubmittingPatches: refer to t/README for tests

There are general guidelines for writing good tests in t/README
but neither SubmittingPatches nor CodingGuidelines refers to it,
which makes the document easy to be missed.

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

Git 2.2.0-rc3

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

mergetools: stop setting $status in merge_cmd()

No callers rely on $status so there's don't need to set
it during merge_cmd() for diffmerge, emerge, and kdiff3.

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

mergetool: simplify conditionals

Combine the $last_status checks into a single conditional.
Replace $last_status and $rollup_status with a single variable.

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

difftool--helper: add explicit exit statement

git-difftool--helper returns a zero exit status unless
--trust-exit-code is in effect.  Add an explicit exit statement
to make this clearer.

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

mergetool--lib: remove use of $status global

Remove return statements and rework check_unchanged() so that the exit
status from the last evaluated expression bubbles up to the callers.

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

mergetool--lib: remove no-op assignment to $status from setup_user_tool

Even though setup_user_tool assigns the exit status from "eval
$merge_tool_cmd" to $status, the variable is overwritten by the
function it calls next, check_unchanged, without ever getting looked
at by anybody.  And "return $status" at the end of this function
returns the value check_unchanged assigned to it (which is the same
as the value the function returns).  Which makes the assignment a
no-op.

Remove it.

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

init-db: improve the filemode trustability check

Some file systems do not support the executable bit:

  a) The user executable bit is always 0, e.g. VFAT mounted with
     -onoexec

  b) The user executable bit is always 1, e.g. cifs mounted with
     -ofile_mode=0755

  c) There are system where user executable bit is 1 even if it
     should be 0 like b), but the file mode can be maintained
     locally. chmod -x changes the file mode from 0766 to 0666,
     until the file system is unmounted and remounted and the file
     mode is 0766 again.

     This been observed when a Windows machine with NTFS exports a share to
     Mac OS X via smb or afp.

Case a) and b) are handled by the current code.  Case c) qualifies
as "non trustable executable bit" and core.filemode should be false,
but this is currently not done.

Detect when ".git/config" has the user executable bit set after
creat(".git/config", 0666) and set core.filemode to false.  Because
the permission bits on the file is whatever the end user already had
when we are asked to reinitialise an existing repository, and do not
give any information on the filesystem behaviour, do this only when
running "git init" to create a new repository.

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

add: ignore only ignored files

"git add foo bar" adds neither foo nor bar when bar is ignored, but dies
to let the user recheck their command invocation. This becomes less
helpful when "git add foo.*" is subject to shell expansion and some of
the expanded files are ignored.

"git add --ignore-errors" is supposed to ignore errors when indexing
some files and adds the others. It does ignore errors from actual
indexing attempts, but does not ignore the error "file is ignored" as
outlined above. This is unexpected.

Change "git add foo bar" to add foo when bar is ignored, but issue
a warning and return a failure code as before the change.

That is, in the case of trying to add ignored files we now act the same
way (with or without "--ignore-errors") in which we act for more
severe indexing errors when "--ignore-errors" is specified.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff-highlight: allow configurable colors

Until now, the highlighting colors were hard-coded in the
script (as "reverse" and "noreverse"), and you had to edit
the script to change them. This patch teaches diff-highlight
to read from color.diff-highlight.* to set them.

In addition, it expands the possiblities considerably by
adding two features:

  1. Old/new lines can be colored independently (so you can
     use a color scheme that complements existing line
     coloring).

  2. Normal, unhighlighted parts of the lines can be colored,
     too. Technically this can be done by separately
     configuring color.diff.old/new and matching it to your
     diff-highlight colors. But you may want a different
     look for your highlighted diffs versus your regular
     diffs.

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

parse_color: recognize "no$foo" to clear the $foo attribute

You can turn on ANSI text attributes like "reverse" by
putting "reverse" in your color spec. However, you cannot
ask to turn reverse off.

For common cases, this does not matter. You would turn on
"reverse" at the start of a colored section, and then clear
all attributes with a "reset". However, you may wish to turn
on some attributes, then selectively disable others. For
example:

  git log --format="%C(bold ul yellow)%h%C(noul) %s"

underlines just the hash, but without the need to re-specify
the rest of the attributes. This can also help third-party
programs, like contrib/diff-highlight, that want to turn
some attribute on/off without disrupting existing coloring.

Note that some attribute specifications are probably
nonsensical (e.g., "bold nobold"). We do not bother to flag
such constructs, and instead let the terminal sort it out.

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

parse_color: support 24-bit RGB values

Some terminals (like XTerm) allow full 24-bit RGB color
specifications using an extension to the regular ANSI color
scheme. Let's allow users to specify hex RGB colors,
enabling the all-important feature of hot pink ref
decorations:

  git log --format="%h%C(#ff69b4)%d%C(reset) %s"

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

parse_color: refactor color storage

When we parse a color name like "red" into its ANSI color
value, we pack the storage into a single int that may take
on many values:

  1. If it's "-2", no value has been specified.

  2. If it's "-1", the value is "normal" (i.e., no color).

  3. If it's 0 through 7, the value is a standard ANSI
     color.

  4. If it's larger (up to 255), it is a 256-color extended
     value.

Given these magic numbers, it is often hard to see what is
going on in the code. Let's refactor this into a struct with
a flag that tells which scheme we are using, along with a
numeric value. This is more verbose, but should hopefully be
simpler to follow. It will also allow us to easily add
support for more schemes, like 24-bit RGB values.

The result is also slightly less efficient to store, but
that's OK; we only store this intermediate state during the
parse, after which we write out the actual ANSI bytes.

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

Merge branch 'jn/parse-config-slot' into jk/colors

* jn/parse-config-slot:
  color_parse: do not mention variable name in error message
  pass config slots as pointers instead of offsets

t4026: test "normal" color

If the user specifiers "normal" for a foreground color, this
should be a noop (while this may sound useless, it is the
only way to specify an unchanged foreground color followed
by a specific background color).

We also check that color "-1" does the same thing. This is
not documented, but has worked forever, so let's make sure
we keep supporting it.

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

config: fix parsing of "git config --get-color some.key -1"

Most of git-config's command line options use OPT_BIT to
choose an action, and then parse the non-option arguments
in a context-dependent way. However, --get-color and
--get-colorbool are unlike the rest of the options, in that
they are OPT_STRING, taking the option name as a parameter.

This generally works, because we then use the presence of
those strings to set an action bit anyway. But it does mean
that the option-parser will continue looking for options
even after the key (because it is not a non-option; it is an
argument to an option). And running:

  git config --get-color some.key -1

(to use "-1" as the default color spec) will barf, claiming
that "-1" is not an option. Instead, we should treat
--get-color and --get-colorbool as action bits, just like
--add, --get, and all the other actions, and then check that
the non-option arguments we got are sane. This fixes the
weirdness above, and makes those two options like all the
others.

This "fixes" a test in t4026, which checked that feeding
"-2" as a color should fail (it does fail, but prior to this
patch, because parseopt barfed, not because we actually ever
tried to parse the color).

This also catches other errors, like:

  git config --get-color some.key black blue

which previously silently ignored "blue" (and now will
complain that you gave too many arguments).

There are some possible regressions, though. We now disallow
these, which currently do what you would expect:

  # specifying other options after the action
  git config --get-color some.key --file whatever

  # using long-arg syntax
  git config --get-color=some.key

However, we have never advertised these in the
documentation, and in fact they did not work in some older
versions of git. The behavior was apparently switched as an
accidental side effect of d64ec16 (git config: reorganize to
use parseopt, 2009-02-21).

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

docs: describe ANSI 256-color mode

Our color specifications have supported the 256-color ANSI
extension for years, but we never documented it.

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

lock_ref_sha1_basic: do not die on locking errors

lock_ref_sha1_basic is inconsistent about when it calls
die() and when it returns NULL to signal an error. This is
annoying to any callers that want to recover from a locking
error.

This seems to be mostly historical accident. It was added in
4bd18c4 (Improve abstraction of ref lock/write.,
2006-05-17), which returned an error in all cases except
calling safe_create_leading_directories, in which case it
died.  Later, 40aaae8 (Better error message when we are
unable to lock the index file, 2006-08-12) asked
hold_lock_file_for_update to die for us, leaving the
resolve_ref code-path the only one which returned NULL.

We tried to correct that in 5cc3cef (lock_ref_sha1(): do not
sometimes error() and sometimes die()., 2006-09-30),
by converting all of the die() calls into returns. But we
missed the "die" flag passed to the lock code, leaving us
inconsistent. This state persisted until e5c223e
(lock_ref_sha1_basic(): if locking fails with ENOENT, retry,
2014-01-18). Because of its retry scheme, it does not ask
the lock code to die, but instead manually dies with
unable_to_lock_die().

We can make this consistent with the other return paths by
converting this to use unable_to_lock_message(), and
returning NULL. This is safe to do because all callers
already needed to check the return value of the function,
since it could fail (and return NULL) for other reasons.

[jk: Added excessive history explanation]

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

l10n: remove a superfluous translation for push.c

Ralf reported that '--recurse-submodules' option in push.c should not be
translated [1].  Before his commit is merged, remove superfluous
translations for push.c.

[1] http://www.spinics.net/lists/git/msg241964.html

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

l10n: de.po: translate 2 messages

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

l10n: de.po: translate 2 new messages

Signed-off-by: Phillip Sz <phillip.szelat@gmail.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>

l10n: batch updates for one trivial change

In order to catch up with the release of Git 2.2.0 final, make a batch
l10n update for the new l10n change brought by commit d52adf1 (trailer:
display a trailer without its trailing newline).

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

l10n: git.pot: v2.2.0 round 2 (1 updated)

Generate po/git.pot from v2.2.0-rc2-23-gca0107e for git v2.2.0 l10n
round 2.

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

Merge branch 'sv/submitting-final-patch'

* sv/submitting-final-patch:
  SubmittingPatches: final submission is To: maintainer and CC: list

Merge branch 'sn/tutorial-status-output-example'

* sn/tutorial-status-output-example:
  gittutorial: fix output of 'git status'

Merge branch 'mh/doc-remote-helper-xref'

* mh/doc-remote-helper-xref:
  doc: add some crossrefs between manual pages

Merge branch 'tb/no-relative-file-url'

* tb/no-relative-file-url:
  t5705: the file:// URL should be absolute

Merge branch 'cc/interpret-trailers'

Small fixes to a new experimental command already in 'master'.

* cc/interpret-trailers:
  trailer: display a trailer without its trailing newline
  trailer: ignore comment lines inside the trailers

gitweb: hack around CGI's list-context param() handling

As of CGI.pm's 4.08 release, the behavior to call
CGI::param() in a list context is deprecated (because it can
be potentially unsafe if called inside a hash constructor).
This causes gitweb to issue a warning for some of our code,
which in turn causes the tests to fail.

Our use is in fact _not_ one of the dangerous cases, as we
are intentionally using a list context. The recommended
route by 4.08 is to use the new CGI::multi_param() call to
make it explicit that we know what we are doing.
However, that function is only available in 4.08, which is
about a month old; we cannot rely on having it.

One option would be to set $CGI::LIST_CONTEXT_WARN globally,
which turns off the warning. However, that would eliminate
the protection these newer releases are trying to provide.
We want to annotate each site as OK using the new function.

So instead, let's check whether CGI provides the
multi_param() function, and if not, provide an
implementation that just wraps param(). That will work on
both old and new versions of CGI. Sadly, we cannot just
check defined(\&CGI::multi_param), because CGI uses the
autoload feature, which claims that all functions are
defined. Instead, we just do a version check.

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

builtin/push.c: fix description of --recurse-submodules option

The description of the option for argument "recurse-submodules"
is marked for translation even if it expects the untranslated
string and it's missing the option "on-demand" which was introduced
in eb21c73 (2014-03-29, push: teach --recurse-submodules the on-demand
option). Fix this by unmark the string for translation and add the
missing option.

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: have python scripts depend on NO_PYTHON setting

Like the perl scripts, python scripts need a dependency to ensure they
are rebuilt when switching between the "dummy" versions that run
without Python and the real thing.

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

Makefile: simplify by using SCRIPT_{PERL,SH}_GEN macros

SCRIPT_PERL_GEN is defined as $(patsubst %.perl,%,$(SCRIPT_PERL))
for use in targets like build-perl-script used by makefiles in
subdirectories that override SCRIPT_PERL (see v1.8.2-rc0~17^2,
"git-remote-mediawiki: use toplevel's Makefile", 2013-02-08).

The same expression is used in the rules that actually write the
generated perl scripts, and since these rules were introduced before
SCRIPT_PERL_GEN, they use the longhand instead of that macro.  Use the
macro to make reading easier.

Likewise for SCRIPT_SH_GEN.  The Python rules already got the same
simplification in v1.8.4-rc0~162^2~8 (2013-05-24).

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

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

* 'master' of git://github.com/git-l10n/git-po:
  l10n: Update Catalan translation

Merge branch 'jc/doc-commit-only'

* jc/doc-commit-only:
  Documentation/git-commit: clarify that --only/--include records the working tree contents

Merge branch 'ta/tutorial-modernize'

* ta/tutorial-modernize:
  gittutorial.txt: remove reference to ancient Git version