use strbuf_complete_line() for adding a newline if needed

Call strbuf_complete_line() instead of open-coding it.  Also remove
surrounding comments indicating the intent to complete a line since
this information is already included in the function name.

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

tests: skip RFC1991 tests for gnupg 2.1

GnuPG >= 2.1.0 no longer supports RFC1991, so skip these tests.

Signed-off-by: Christian Hesse <mail@eworm.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

tests: create gpg homedir on the fly

GnuPG 2.1 homedir looks different, so just create it on the fly by
importing needed private and public keys and ownertrust.

This solves an issue with gnupg 2.1 running interactive pinentry
when old secret key is present.

Signed-off-by: Christian Hesse <mail@eworm.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: always populate GIT_AUTHOR_* variables

To figure out the author ident for a commit, we call
determine_author_info(). This function collects information
from the environment, other commits (in the case of
"--amend" or "-c/-C"), and the "--author" option. It then
uses fmt_ident to generate the final ident string that goes
into the commit object. fmt_ident is therefore responsible
for any quality or validation checks on what is allowed to
go into a commit.

Before returning, though, we call split_ident_line on the
result, and feed the individual components to hooks via the
GIT_AUTHOR_* variables. Furthermore, we do extra validation
by feeding the split to sane_ident_split(), which is pickier
than fmt_ident (in particular, it will complain about an empty
email field).  If this parsing or validation fails, we skip
updating the environment variables.

This is bad, because it means that hooks may silently see a
different ident than what we are putting into the commit. We
should drop the extra sane_ident_split checks entirely, and
take whatever fmt_ident has fed us (and what will go into
the commit object).

If parsing fails, we should actually abort here rather than
continuing (and feeding the hooks bogus data). However,
split_ident_line should never fail here. The ident was just
generated by fmt_ident, so we know that it's sane. We can
use assert_split_ident to double-check this.

Note that we also teach that assertion to check that we
found a date (it always should, but until now, no caller
cared whether we found a date or not). Checking the return
value of sane_ident_split is enough to ensure we have the
name/email pointers set, and checking date_begin is enough
to know that all of the date/tz variables are set.

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

commit: loosen ident checks when generating template

When we generate the commit-message template, we try to
report an author or committer ident that will be of interest
to the user: an author that does not match the committer, or
a committer that was auto-configured.

When doing so, if we encounter what we consider to be a
bogus ident, we immediately die. This is a bad idea, because
our use of the idents here is purely informational.  Any
ident rules should be enforced elsewhere, because commits
that do not invoke the editor will not even hit this code
path (e.g., "git commit -mfoo" would work, but "git commit"
would not). So at best, we are redundant with other checks,
and at worse, we actively prevent commits that should
otherwise be allowed.

We should therefore do the minimal parsing we can to get a
value and not do any validation (i.e., drop the call to
sane_ident_split()).

In theory we could notice when even our minimal parsing
fails to work, and do the sane thing for each check (e.g.,
if we have an author but can't parse the committer, assume
they are different and print the author). But we can
actually simplify this even further.

We know that the author and committer strings we are parsing
have been generated by us earlier in the program, and
therefore they must be parseable. We could just call
split_ident_line without even checking its return value,
knowing that it will put _something_ in the name/mail
fields. Of course, to protect ourselves against future
changes to the code, it makes sense to turn this into an
assert, so we are not surprised if our assumption fails.

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

index-format.txt: add a missing closing quote

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

t: support clang/gcc AddressSanitizer

When git is compiled with "-fsanitize=address" (using clang
or gcc >= 4.8), all invocations of git will check for buffer
overflows. This is similar to running with valgrind, except
that it is more thorough (because of the compiler support,
function-local buffers can be checked, too) and runs much
faster (making it much less painful to run the whole test
suite with the checks turned on).

Unlike valgrind, the magic happens at compile-time, so we
don't need the same infrastructure in the test suite that we
did to support --valgrind. But there are two things we can
help with:

  1. On some platforms, the leak-detector is on by default,
     and causes every invocation of "git init" (and thus
     every test script) to fail. Since running git with
     the leak detector is pointless, let's shut it off
     automatically in the tests, unless the user has already
     configured it.

  2. When apache runs a CGI, it clears the environment of
     unknown variables. This means that the $ASAN_OPTIONS
     config doesn't make it to git-http-backend, and it
     dies due to the leak detector. Let's mark the variable
     as OK for apache to pass.

With these two changes, running

    make CC=clang CFLAGS=-fsanitize=address test

works out of the box.

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

update-ref: fix "verify" command with missing <oldvalue>

If "git update-ref --stdin" was given a "verify" command with no
"<newvalue>" at all (not even zeros), the code was mistakenly setting
have_old=0 (and leaving old_sha1 uninitialized). But this is
incorrect: this command is supposed to verify that the reference
doesn't exist. So in this case we really need old_sha1 to be set to
null_sha1 and have_old to be set to 1.

Moreover, since have_old was being set to zero, *no* check of the old
value was being done, so the new value of the reference was being set
unconditionally to the value in new_sha1. new_sha1, in turn, was set
to null_sha1 in the expectation that that was the old value and it
shouldn't be changed. But because the precondition was not being
checked, the result was that the reference was being deleted
unconditionally.

So, if <oldvalue> is missing, set have_old unconditionally and set
old_sha1 to null_sha1.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Acked-by: Brad King <brad.king@kitware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t1400: add some more tests of "update-ref --stdin"'s verify command

Two of the tests fail because

    verify refs/heads/foo

with no argument (not even zeros) actually *deletes* refs/heads/foo.
This problem will be fixed in the next commit.

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

Show number of TODO items for interactive rebase

During 'rebase -i', one wrong edit in a long rebase session
might inadvertently drop commits/items. This change shows
the total number of TODO items in the comments after the
list. After performing the rebase edit, total item counts
can be compared to make sure that no changes have been lost
in the edit.

Signed-off-by: Onno Kortmann <onno@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pkt-line: allow writing of LARGE_PACKET_MAX buffers

When we send out pkt-lines with refnames, we use a static
1000-byte buffer. This means that the maximum size of a ref
over the git protocol is around 950 bytes (the exact size
depends on the protocol line being written, but figure on a sha1
plus some boilerplate).

This is enough for any sane workflow, but occasionally odd
things happen (e.g., a bug may create a ref "foo/foo/foo/..."
accidentally).  With the current code, you cannot even use
"push" to delete such a ref from a remote.

Let's switch to using a strbuf, with a hard-limit of
LARGE_PACKET_MAX (which is specified by the protocol).  This
matches the size of the readers, as of 74543a0 (pkt-line:
provide a LARGE_PACKET_MAX static buffer, 2013-02-20).
Versions of git older than that will complain about our
large packets, but it's really no worse than the current
behavior. Right now the sender barfs with "impossibly long
line" trying to send the packet, and afterwards the reader
will barf with "protocol error: bad line length %d", which
is arguably better anyway.

Note that we're not really _solving_ the problem here, but
just bumping the limits. In theory, the length of a ref is
unbounded, and pkt-line can only represent sizes up to
65531 bytes. So we are just bumping the limit, not removing
it.  But hopefully 64K should be enough for anyone.

As a bonus, by using a strbuf for the formatting we can
eliminate an unnecessary copy in format_buf_write.

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

read_packed_refs: use skip_prefix instead of static array

We want to recognize the packed-refs header and skip to the
"traits" part of the line. We currently do it by feeding
sizeof() a static const array to strncmp. However, it's a
bit simpler to just skip_prefix, which expresses the
intention more directly, and without remembering to account
for the NUL-terminator in each sizeof() call.

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

read_packed_refs: pass strbuf to parse_ref_line

Now that we have a strbuf in read_packed_refs, we can pass
it straight to the line parser, which saves us an extra
strlen.

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

read_packed_refs: use a strbuf for reading lines

Current code uses a fixed PATH_MAX-sized buffer for reading
packed-refs lines. This is a reasonable guess, in the sense
that git generally cannot work with refs larger than
PATH_MAX.  However, there are a few cases where it is not
great:

  1. Some systems may have a low value of PATH_MAX, but can
     actually handle larger paths in practice. Fixing this
     code path probably isn't enough to make them work
     completely with long refs, but it is a step in the
     right direction.

  2. We use fgets, which will happily give us half a line on
     the first read, and then the rest of the line on the
     second. This is probably OK in practice, because our
     refline parser is careful enough to look for the
     trailing newline on the first line. The second line may
     look like a peeled line to us, but since "^" is illegal
     in refnames, it is not likely to come up.

     Still, it does not hurt to be more careful.

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

branch: allow -f with -m and -d

-f/--force is the standard way to force an action, and is used by branch
for the recreation of existing branches, but not for deleting unmerged
branches nor for renaming to an existing branch.

Make "-m -f" equivalent to "-M" and "-d -f" equivalent to" -D", i.e.
allow -f/--force to be used with -m/-d also.

For the list modes, "-f" is simply ignored.

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

parse_color: drop COLOR_BACKGROUND macro

Commit 695d95d (parse_color: refactor color storage,
2014-11-20) introduced two macros, COLOR_FOREGROUND and
COLOR_BACKGROUND. The latter conflicts with a system macro
defined on Windows, breaking compilation there.

The simplest solution is to just get rid of these macros
entirely. They are constants that are only used in one place
(since the whole point of 695d95d was to avoid repeating
ourselves). Their main function is to make the magic
character constants more readable, but we can do the same
thing with a comment.

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

git-am.txt: --ignore-date flag is not passed to git-apply

Signed-off-by: Ronald Wampler <rdwampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitignore.txt: do not suggest assume-unchanged

git-update-index --assume-unchanged was never meant to ignore changes
to tracked files (only to spare some stats). So do not suggest it
as a means to achieve that.

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

doc: make clear --assume-unchanged's user contract

Many users misunderstand the --assume-unchanged contract, believing
it means Git won't look at the flagged file.

Be explicit that the --assume-unchanged contract is by the user that
they will NOT change the file so that Git does not need to look (and
expend, for example, lstat(2) cycles)

Mentioning "Git stops checking" does not help the reader, as it is
only one possible consequence of what that assumption allows Git to
do, but

   (1) there are things other than "stop checking" that Git can do
       based on that assumption; and
   (2) Git is not obliged to stop checking; it merely is allowed to.

Also, this is a single flag bit, correct the plural to singular, and
the verb, accordingly.

Drop the stale and incorrect information about "poor-man's ignore",
which is not what this flag bit is about at all.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-svn: support for git-svn propset

This change allows git-svn to support setting subversion properties.

It is useful for manually setting properties when committing to a
subversion repo that *requires* properties to be set without requiring
moving your changeset to separate subversion checkout in order to
set props.

This change is initially from David Fraser, appearing at:

  http://mid.gmane.org/1927112650.1281253084529659.JavaMail.root@klofta.sjsoft.com>

They are now forward-ported to most recent git along with fixes to
deal with files in subdirectories.

Style and functional changes from Eric Wong have been taken
in their entirety from:

  http://mid.gmane.org/20141201094911.GA13931@dcvr.yhbt.net

There is a nit to point out: the code does not support
adding props unless there are also content changes to the files as
well.  This is demonstrated in the testcase.

[ew - simplify Git.pm usage for check-attr
    - improve shell portability for tests
    - minor phrasing changes in commit message]

Signed-off-by: David Fraser <davidf@sjsoft.com>
Signed-off-by: Alfred Perlstein <alfred@freebsd.org>
Signed-off-by: Eric Wong <normalperson@yhbt.net>

test-hashmap: squelch gcc compiler warning

At least on this developer's MacOSX (Snow Leopard, gcc-4.2.1), GCC
prints a warning that 'hash' may be used uninitialized when
compiling test-hashmap that 'hash' may be used uninitialized (but
GCC 4.6.3 on this developer's Ubuntu server does not report this
problem).

The old compiler is wrong, of course, as the switch (method & 3)
statement already handles all the possible cases, but that does not
help in a scenario where it is hard or impossible to upgrade to a
newer compiler (e.g. being stuck on an older MacOSX and having to
rely on Xcode).

So let's just initialize the variable and be done with it, it is
hardly a crucial part of the code because it is only used by the
test suite and invisible to the end users.

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

index-pack: terminate object buffers with NUL

We have some tricky checks in fsck that rely on a side effect of
require_end_of_header(), and would otherwise easily run outside
non-NUL-terminated buffers. This is a bit brittle, so let's make sure
that only NUL-terminated buffers are passed around to begin with.

Jeff "Peff" King contributed the detailed analysis which call paths are
involved and pointed out that we also have to patch the get_data()
function in unpack-objects.c, which is what Johannes "Dscho" Schindelin
implemented.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Analyzed-by: Jeff King <peff@peff.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fsck: properly bound "invalid tag name" error message

When we detect an invalid tag-name header in a tag object,
like, "tag foo bar\n", we feed the pointer starting at "foo
bar" to a printf "%s" formatter. This shows the name, as we
want, but then it keeps printing the rest of the tag buffer,
rather than stopping at the end of the line.

Our tests did not notice because they look only for the
matching line, but the bug is that we print much more than
we wanted to. So we also adjust the test to be more exact.

Note that when fscking tags with "index-pack --strict", this
is even worse. index-pack does not add a trailing
NUL-terminator after the object, so we may actually read
past the buffer and print uninitialized memory. Running
t5302 with valgrind does notice the bug for that reason.

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

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>