Merge branch 'mh/simplify-repack-without-refs'

"git remote update --prune" to drop many refs has been optimized.

* mh/simplify-repack-without-refs:
  sort_string_list(): rename to string_list_sort()
  prune_remote(): iterate using for_each_string_list_item()
  prune_remote(): rename local variable
  repack_without_refs(): make the refnames argument a string_list
  prune_remote(): sort delete_refs_list references en masse
  prune_remote(): initialize both delete_refs lists in a single loop
  prune_remote(): exit early if there are no stale references

Merge branch 'dw/shell-basename-dashdash-before-stripping-leading-dash-from-login'

* dw/shell-basename-dashdash-before-stripping-leading-dash-from-login:
  git-sh-setup.sh: use dashdash with basename call

Merge branch 'rj/no-xopen-source-for-cygwin'

Avoid compilation warnings on recent gcc toolchain on Cygwin.

* rj/no-xopen-source-for-cygwin:
  git-compat-util.h: don't define _XOPEN_SOURCE on cygwin

Merge branch 'js/t5000-dont-copy-bin-sh'

* js/t5000-dont-copy-bin-sh:
  t5000 on Windows: do not mistake "sh.exe" as "sh"

Merge branch 'jc/refer-to-t-readme-from-submitting-patches'

* jc/refer-to-t-readme-from-submitting-patches:
  t/README: justify why "! grep foo" is sufficient
  SubmittingPatches: refer to t/README for tests

Merge branch 'tb/config-core-filemode-check-on-broken-fs'

Some filesystems assign filemodes in a strange way, fooling then
automatic "filemode trustability" check done during a new
repository creation.

* tb/config-core-filemode-check-on-broken-fs:
  init-db: improve the filemode trustability check

Merge branch 'mg/add-ignore-errors'

"git add --ignore-errors ..." did not ignore an error to
give a file that did not exist.

* mg/add-ignore-errors:
  add: ignore only ignored files

Merge branch 'jk/lock-ref-sha1-basic-return-errors'

Correct an API anomaly.

* jk/lock-ref-sha1-basic-return-errors:
  lock_ref_sha1_basic: do not die on locking errors

Merge branch 'cc/interpret-trailers-more'

"git interpret-trailers" learned to properly handle the
"Conflicts:" block at the end.

* cc/interpret-trailers-more:
  trailer: add test with an old style conflict block
  trailer: reuse ignore_non_trailer() to ignore conflict lines
  commit: make ignore_non_trailer() non static
  merge & sequencer: turn "Conflicts:" hint into a comment
  builtin/commit.c: extract ignore_non_trailer() helper function
  merge & sequencer: unify codepaths that write "Conflicts:" hint
  builtin/merge.c: drop a parameter that is never used

Prepare for 2.2.2

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

Merge branch 'jk/rebuild-perl-scripts-with-no-perl-seting-change' into maint

The build procedure did not bother fixing perl and python scripts
when NO_PERL and NO_PYTHON build-time configuration changed.

* jk/rebuild-perl-scripts-with-no-perl-seting-change:
  Makefile: have python scripts depend on NO_PYTHON setting
  Makefile: simplify by using SCRIPT_{PERL,SH}_GEN macros
  Makefile: have perl scripts depend on NO_PERL setting

Merge branch 'jk/no-perl-tests' into maint

Some tests that depend on perl lacked PERL prerequisite to protect
them, breaking build with NO_PERL configuration.

* jk/no-perl-tests:
  t960[34]: mark cvsimport tests as requiring perl
  t0090: mark add-interactive test with PERL prerequisite

Merge branch 'po/everyday-doc' into maint

"Everyday" document had a broken link.

* po/everyday-doc:
  Documentation: change "gitlink" typo in git-push

Merge branch 'jk/push-simple' into maint

Git 2.0 was supposed to make the "simple" mode for the default of
"git push", but it didn't.

* jk/push-simple:
  push: truly use "simple" as default, not "upstream"

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

"git init" (hence "git clone") initialized the per-repository
configuration file .git/config with x-bit by mistake.

* 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' into maint

"gitweb" used to depend on a behaviour that was deprecated by recent
CGI.pm.

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

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

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

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

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

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

open() emulated on Windows platforms did not give EISDIR upon an
attempt to open a directory for writing.

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

Merge branch 'jk/colors-fix' into maint

"git config --get-color" did not parse its command line arguments
carefully.

* jk/colors-fix:
  t4026: test "normal" color
  config: fix parsing of "git config --get-color some.key -1"
  docs: describe ANSI 256-color mode

Merge branch 'jk/checkout-from-tree' into maint

"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

Documentation: add missing article in rev-list-options.txt

Add the missing article "a".

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

git-prompt: preserve value of $? inside shell prompt

If you have a prompt which displays the command exit status,
__git_ps1 without this change corrupts it, although it has
the correct value in the parent shell:

~/src/git (master) 0 $ set | grep ^PS1
PS1='\w$(__git_ps1) $? \$ '
~/src/git (master) 0 $ false
~/src/git (master) 0 $ echo $?
1
~/src/git (master) 0 $

There is a slightly ugly workaround:

~/src/git (master) 0 $ set | grep ^PS1
PS1='\w$(x=$?; __git_ps1; exit $x) $? \$ '
~/src/git (master) 0 $ false
~/src/git (master) 1 $

This change makes the workaround unnecessary.

Signed-off-by: Tony Finch <dot@dotat.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

pre-push.sample: remove unnecessary and misleading IFS=' '

The sample hook explicitly sets IFS to SP and nothing else so that
the "read" used in the per-ref while loop that iterates over
"<localref> SP <localsha1> SP <remoteref> SP <remotesha>" records,
where we know refs and sha1s will not have SPs, would split them
correctly.

While this is not wrong per-se, it is not necessary; because we know
these fields do not contain HT or LF, either, we can simply leave
IFS the default.

This will also prevent those who cut and paste from this sample from
getting bitten when they write things in the per-ref loop that need
splitting with the default $IFS (e.g. use $(git rev-list ...) to
produce one-record-per-line output).

Signed-off-by: Jim Hill <gjthill@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

update_unicode.sh: delete the command group

Now that the whole file is generated by one single command, the
command group is no longer needed.

Signed-off-by: Beat Bolli <dev+git@drbeat.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

update_unicode.sh: make the output structure visible

By using a here document instead of the echo/uniset sequence, the
final structure of the generated file becomes obvious.

Signed-off-by: Beat Bolli <dev+git@drbeat.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

update_unicode.sh: shorten uniset invocation path

"uniset/uniset" is a relative path; there's no need to prefix it
with "./".

Signed-off-by: Beat Bolli <dev+git@drbeat.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

update_unicode.sh: set UNICODE_DIR only once

The value is the same on both uniset invocations, so "Don't Repeat
Yourself" applies.

Since this is done as the last command in the sequence, there's no
need to unset UNICODE_DIR at the end.

Signed-off-by: Beat Bolli <dev+git@drbeat.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

update_unicode.sh: simplify output capture

Instead of capturing the output of each echo and uniset invocation,
wrap the whole section in a group command and redirect its output
all at once.

Signed-off-by: Beat Bolli <dev+git@drbeat.li>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

clean: typofix

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

Documentation/SubmittingPatches: unify whitespace/tabs for the DCO

The Developers Certificate of Origin has a mixture of tabs and white
spaces which is annoying to view if your editor explicitly views white
space characters.

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

Sync with v2.2.1

* maint:
  Git 2.2.1
  Git 2.1.4
  Git 2.0.5
  Git 1.9.5
  Git 1.8.5.6
  fsck: complain about NTFS ".git" aliases in trees
  read-cache: optionally disallow NTFS .git variants
  path: add is_ntfs_dotgit() helper
  fsck: complain about HFS+ ".git" aliases in trees
  read-cache: optionally disallow HFS+ .git variants
  utf8: add is_hfs_dotgit() helper
  fsck: notice .git case-insensitively
  t1450: refactor ".", "..", and ".git" fsck tests
  verify_dotfile(): reject .git case-insensitively
  read-tree: add tests for confusing paths like ".." and ".git"
  unpack-trees: propagate errors adding entries to the index

git-compat-util: suppress unavoidable Apple-specific deprecation warnings

With the release of Mac OS X 10.7 in July 2011, Apple deprecated all
openssl.h functionality due to OpenSSL ABI (application binary
interface) instability, resulting in an explosion of compilation
warnings about deprecated SSL, SHA1, and X509 functions (among others).

61067954ce (cache.h: eliminate SHA-1 deprecation warnings on Mac OS X;
2013-05-19) and be4c828b76 (imap-send: eliminate HMAC deprecation
warnings on Mac OS X; 2013-05-19) attempted to ameliorate the situation
by taking advantage of drop-in replacement functionality provided by
Apple's (ABI-stable) CommonCrypto facility, however CommonCrypto
supplies only a subset of deprecated OpenSSL functionality, thus a host
of warnings remain.

Despite this shortcoming, it was hoped that Apple would ultimately
provide CommonCrypto replacements for all deprecated OpenSSL
functionality, and that the effort started by 61067954ce and be4c828b76
would be continued and eventually eliminate all deprecation warnings.
However, now 3.5 years later, and with Mac OS X at 10.10, the hoped-for
CommonCrypto replacements have not yet materialized, nor is there any
indication that they will be forthcoming.

These Apple-specific warnings are pure noise: they don't tell us
anything useful and we have no control over them, nor is Apple likely to
provide replacements any time soon. Such noise may obscure other
legitimate warnings, therefore silence them.

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

Git 2.2.1

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

Sync with v2.1.4

* maint-2.1:
  Git 2.1.4
  Git 2.0.5
  Git 1.9.5
  Git 1.8.5.6
  fsck: complain about NTFS ".git" aliases in trees
  read-cache: optionally disallow NTFS .git variants
  path: add is_ntfs_dotgit() helper
  fsck: complain about HFS+ ".git" aliases in trees
  read-cache: optionally disallow HFS+ .git variants
  utf8: add is_hfs_dotgit() helper
  fsck: notice .git case-insensitively
  t1450: refactor ".", "..", and ".git" fsck tests
  verify_dotfile(): reject .git case-insensitively
  read-tree: add tests for confusing paths like ".." and ".git"
  unpack-trees: propagate errors adding entries to the index

Git 2.1.4

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

Sync with v2.0.5

* maint-2.0:
  Git 2.0.5
  Git 1.9.5
  Git 1.8.5.6
  fsck: complain about NTFS ".git" aliases in trees
  read-cache: optionally disallow NTFS .git variants
  path: add is_ntfs_dotgit() helper
  fsck: complain about HFS+ ".git" aliases in trees
  read-cache: optionally disallow HFS+ .git variants
  utf8: add is_hfs_dotgit() helper
  fsck: notice .git case-insensitively
  t1450: refactor ".", "..", and ".git" fsck tests
  verify_dotfile(): reject .git case-insensitively
  read-tree: add tests for confusing paths like ".." and ".git"
  unpack-trees: propagate errors adding entries to the index

Git 2.0.5

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

Sync with v1.9.5

* maint-1.9:
  Git 1.9.5
  Git 1.8.5.6
  fsck: complain about NTFS ".git" aliases in trees
  read-cache: optionally disallow NTFS .git variants
  path: add is_ntfs_dotgit() helper
  fsck: complain about HFS+ ".git" aliases in trees
  read-cache: optionally disallow HFS+ .git variants
  utf8: add is_hfs_dotgit() helper
  fsck: notice .git case-insensitively
  t1450: refactor ".", "..", and ".git" fsck tests
  verify_dotfile(): reject .git case-insensitively
  read-tree: add tests for confusing paths like ".." and ".git"
  unpack-trees: propagate errors adding entries to the index

Git 1.9.5

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

Sync with v1.8.5.6

* maint-1.8.5:
  Git 1.8.5.6
  fsck: complain about NTFS ".git" aliases in trees
  read-cache: optionally disallow NTFS .git variants
  path: add is_ntfs_dotgit() helper
  fsck: complain about HFS+ ".git" aliases in trees
  read-cache: optionally disallow HFS+ .git variants
  utf8: add is_hfs_dotgit() helper
  fsck: notice .git case-insensitively
  t1450: refactor ".", "..", and ".git" fsck tests
  verify_dotfile(): reject .git case-insensitively
  read-tree: add tests for confusing paths like ".." and ".git"
  unpack-trees: propagate errors adding entries to the index

Git 1.8.5.6

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

Merge branch 'dotgit-case-maint-1.8.5' into maint-1.8.5

* dotgit-case-maint-1.8.5:
  fsck: complain about NTFS ".git" aliases in trees
  read-cache: optionally disallow NTFS .git variants
  path: add is_ntfs_dotgit() helper
  fsck: complain about HFS+ ".git" aliases in trees
  read-cache: optionally disallow HFS+ .git variants
  utf8: add is_hfs_dotgit() helper
  fsck: notice .git case-insensitively
  t1450: refactor ".", "..", and ".git" fsck tests
  verify_dotfile(): reject .git case-insensitively
  read-tree: add tests for confusing paths like ".." and ".git"
  unpack-trees: propagate errors adding entries to the index

fsck: complain about NTFS ".git" aliases in trees

Now that the index can block pathnames that can be mistaken
to mean ".git" on NTFS and FAT32, it would be helpful for
fsck to notice such problematic paths. This lets servers
which use receive.fsckObjects block them before the damage
spreads.

Note that the fsck check is always on, even for systems
without core.protectNTFS set. This is technically more
restrictive than we need to be, as a set of users on ext4
could happily use these odd filenames without caring about
NTFS.

However, on balance, it's helpful for all servers to block
these (because the paths can be used for mischief, and
servers which bother to fsck would want to stop the spread
whether they are on NTFS themselves or not), and hardly
anybody will be affected (because the blocked names are
variants of .git or git~1, meaning mischief is almost
certainly what the tree author had in mind).

Ideally these would be controlled by a separate
"fsck.protectNTFS" flag. However, it would be much nicer to
be able to enable/disable _any_ fsck flag individually, and
any scheme we choose should match such a system. Given the
likelihood of anybody using such a path in practice, it is
not unreasonable to wait until such a system materializes.

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

read-cache: optionally disallow NTFS .git variants

The point of disallowing ".git" in the index is that we
would never want to accidentally overwrite files in the
repository directory. But this means we need to respect the
filesystem's idea of when two paths are equal. The prior
commit added a helper to make such a comparison for NTFS
and FAT32; let's use it in verify_path().

We make this check optional for two reasons:

  1. It restricts the set of allowable filenames, which is
     unnecessary for people who are not on NTFS nor FAT32.
     In practice this probably doesn't matter, though, as
     the restricted names are rather obscure and almost
     certainly would never come up in practice.

  2. It has a minor performance penalty for every path we
     insert into the index.

This patch ties the check to the core.protectNTFS config
option. Though this is expected to be most useful on Windows,
we allow it to be set everywhere, as NTFS may be mounted on
other platforms. The variable does default to on for Windows,
though.

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

path: add is_ntfs_dotgit() helper

We do not allow paths with a ".git" component to be added to
the index, as that would mean repository contents could
overwrite our repository files. However, asking "is this
path the same as .git" is not as simple as strcmp() on some
filesystems.

On NTFS (and FAT32), there exist so-called "short names" for
backwards-compatibility: 8.3 compliant names that refer to the same files
as their long names. As ".git" is not an 8.3 compliant name, a short name
is generated automatically, typically "git~1".

Depending on the Windows version, any combination of trailing spaces and
periods are ignored, too, so that both "git~1." and ".git." still refer
to the Git directory. The reason is that 8.3 stores file names shorter
than 8 characters with trailing spaces. So literally, it does not matter
for the short name whether it is padded with spaces or whether it is
shorter than 8 characters, it is considered to be the exact same.

The period is the separator between file name and file extension, and
again, an empty extension consists just of spaces in 8.3 format. So
technically, we would need only take care of the equivalent of this
regex:
        (\.git {0,4}|git~1 {0,3})\. {0,3}

However, there are indications that at least some Windows versions might
be more lenient and accept arbitrary combinations of trailing spaces and
periods and strip them out. So we're playing it real safe here. Besides,
there can be little doubt about the intention behind using file names
matching even the more lenient pattern specified above, therefore we
should be fine with disallowing such patterns.

Extra care is taken to catch names such as '.\\.git\\booh' because the
backslash is marked as a directory separator only on Windows, and we want
to use this new helper function also in fsck on other platforms.

A big thank you goes to Ed Thomson and an unnamed Microsoft engineer for
the detailed analysis performed to come up with the corresponding fixes
for libgit2.

This commit adds a function to detect whether a given file name can refer
to the Git directory by mistake.

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

fsck: complain about HFS+ ".git" aliases in trees

Now that the index can block pathnames that case-fold to
".git" on HFS+, it would be helpful for fsck to notice such
problematic paths. This lets servers which use
receive.fsckObjects block them before the damage spreads.

Note that the fsck check is always on, even for systems
without core.protectHFS set. This is technically more
restrictive than we need to be, as a set of users on ext4
could happily use these odd filenames without caring about
HFS+.

However, on balance, it's helpful for all servers to block
these (because the paths can be used for mischief, and
servers which bother to fsck would want to stop the spread
whether they are on HFS+ themselves or not), and hardly
anybody will be affected (because the blocked names are
variants of .git with invisible Unicode code-points mixed
in, meaning mischief is almost certainly what the tree
author had in mind).

Ideally these would be controlled by a separate
"fsck.protectHFS" flag. However, it would be much nicer to
be able to enable/disable _any_ fsck flag individually, and
any scheme we choose should match such a system. Given the
likelihood of anybody using such a path in practice, it is
not unreasonable to wait until such a system materializes.

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

read-cache: optionally disallow HFS+ .git variants

The point of disallowing ".git" in the index is that we
would never want to accidentally overwrite files in the
repository directory. But this means we need to respect the
filesystem's idea of when two paths are equal. The prior
commit added a helper to make such a comparison for HFS+;
let's use it in verify_path.

We make this check optional for two reasons:

  1. It restricts the set of allowable filenames, which is
     unnecessary for people who are not on HFS+. In practice
     this probably doesn't matter, though, as the restricted
     names are rather obscure and almost certainly would
     never come up in practice.

  2. It has a minor performance penalty for every path we
     insert into the index.

This patch ties the check to the core.protectHFS config
option. Though this is expected to be most useful on OS X,
we allow it to be set everywhere, as HFS+ may be mounted on
other platforms. The variable does default to on for OS X,
though.

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

utf8: add is_hfs_dotgit() helper

We do not allow paths with a ".git" component to be added to
the index, as that would mean repository contents could
overwrite our repository files. However, asking "is this
path the same as .git" is not as simple as strcmp() on some
filesystems.

HFS+'s case-folding does more than just fold uppercase into
lowercase (which we already handle with strcasecmp). It may
also skip past certain "ignored" Unicode code points, so
that (for example) ".gi\u200ct" is mapped ot ".git".

The full list of folds can be found in the tables at:

  https://www.opensource.apple.com/source/xnu/xnu-1504.15.3/bsd/hfs/hfscommon/Unicode/UCStringCompareData.h

Implementing a full "is this path the same as that path"
comparison would require us importing the whole set of
tables.  However, what we want to do is much simpler: we
only care about checking ".git". We know that 'G' is the
only thing that folds to 'g', and so on, so we really only
need to deal with the set of ignored code points, which is
much smaller.

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

fsck: notice .git case-insensitively

We complain about ".git" in a tree because it cannot be
loaded into the index or checked out. Since we now also
reject ".GIT" case-insensitively, fsck should notice the
same, so that errors do not propagate.

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

t1450: refactor ".", "..", and ".git" fsck tests

We check that fsck notices and complains about confusing
paths in trees. However, there are a few shortcomings:

  1. We check only for these paths as file entries, not as
     intermediate paths (so ".git" and not ".git/foo").

  2. We check "." and ".." together, so it is possible that
     we notice only one and not the other.

  3. We repeat a lot of boilerplate.

Let's use some loops to be more thorough in our testing, and
still end up with shorter code.

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

verify_dotfile(): reject .git case-insensitively

We do not allow ".git" to enter into the index as a path
component, because checking out the result to the working
tree may causes confusion for subsequent git commands.
However, on case-insensitive file systems, ".Git" or ".GIT"
is the same. We should catch and prevent those, too.

Note that technically we could allow this for repos on
case-sensitive filesystems. But there's not much point. It's
unlikely that anybody cares, and it creates a repository
that is unexpectedly non-portable to other systems.

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

read-tree: add tests for confusing paths like ".." and ".git"

We should prevent nonsense paths from entering the index in
the first place, as they can cause confusing results if they
are ever checked out into the working tree. We already do
so, but we never tested it.

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

unpack-trees: propagate errors adding entries to the index

When unpack_trees tries to write an entry to the index,
add_index_entry may report an error to stderr, but we ignore
its return value. This leads to us returning a successful
exit code for an operation that partially failed. Let's make
sure to propagate this code.

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

tests: make comment on GPG keyring match the code

GnuPG homedir is generated on the fly and keys are imported from
armored key file. Make comment match available key info and new key
generation procedure.

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

t5400: remove dead code

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

test/send-email: --[no-]xmailer tests

Add tests for the --[no-]xmailer option.

Signed-off-by: Luis Henriques <henrix@camandro.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: add --[no-]xmailer option

Add --[no-]xmailer that allows a user to disable adding the 'X-Mailer:'
header to the email being sent.

Signed-off-by: Luis Henriques <henrix@camandro.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add--interactive: leave main loop on read error

The main hunk loop for add--interactive will loop if it does
not get a known input. This is a good thing if the user
typed some invalid input. However, if we have an
uncorrectable read error, we'll end up looping infinitely.
We can fix this by noticing read errors (i.e., <STDIN>
returns undef) and breaking out of the loop.

One easy way to trigger this is if you have an editor that
does not take over the terminal (e.g., one that spawns a
window in an existing process and waits), start the editor
with the hunk-edit command, and hit ^C to send SIGINT. The
editor process dies due to SIGINT, but the perl
add--interactive process does not (perl suspends SIGINT for
the duration of our system() call).

We return to the main loop, but further reads from stdin
don't work. The SIGINT _also_ killed our parent git process,
which orphans our process group, meaning that further reads
from the terminal will always fail. We loop infinitely,
getting EIO on each read.

Note that there are several other spots where we read from
stdin, too. However, in each of those cases, we do something
sane when the read returns undef (breaking out of the loop,
taking the input as "no", etc). They don't need similar
treatment.

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

Update documentation occurrences of filename .sh

Documentation in the completion scripts for Bash and Zsh state the wrong filenames.

Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: handle adjacent RFC 2047-encoded words properly

The RFC says that they are to be concatenated after decoding (i.e. the
intervening whitespace is ignored).

Signed-off-by: Роман Донченко <dpb@corrigendum.ru>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-email: align RFC 2047 decoding more closely with the spec

More specifically:

* Add "\" to the list of characters not allowed in a token (see RFC 2047
  errata).

* Share regexes between unquote_rfc2047 and is_rfc2047_quoted. Besides
  removing duplication, this also makes unquote_rfc2047 more stringent.

* Allow both "q" and "Q" to identify the encoding.

* Allow lowercase hexadecimal digits in the "Q" encoding.

And, more on the cosmetic side:

* Change the "encoded-text" regex to exclude rather than include characters,
  for clarity and consistency with "token".

Signed-off-by: Роман Донченко <dpb@corrigendum.ru>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-prompt.sh: make $f local to __git_eread()

This function uses (non-local) $f to store the value of its first parameter.
This can interfere with the user's environment.

Signed-off-by: Justin Guenther <jguenther@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Second batch for 2.3 cycle

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

Merge branch 'jk/pack-bitmap'

* jk/pack-bitmap:
  pack-bitmap: do not use gcc packed attribute

Merge branch 'jk/push-simple'

Git 2.0 was supposed to make the "simple" mode for the default of
"git push", but it didn't.

* jk/push-simple:
  push: truly use "simple" as default, not "upstream"

Merge branch 'da/difftool-mergetool-simplify-reporting-status'

Code simplification.

* da/difftool-mergetool-simplify-reporting-status:
  mergetools: stop setting $status in merge_cmd()
  mergetool: simplify conditionals
  difftool--helper: add explicit exit statement
  mergetool--lib: remove use of $status global
  mergetool--lib: remove no-op assignment to $status from setup_user_tool

Merge branch 'jk/colors-fix'

* jk/colors-fix:
  t4026: test "normal" color
  config: fix parsing of "git config --get-color some.key -1"
  docs: describe ANSI 256-color mode

Merge branch 'rt/push-recurse-submodule-usage-string'

* rt/push-recurse-submodule-usage-string:
  builtin/push.c: fix description of --recurse-submodules option

Merge branch 'jk/rebuild-perl-scripts-with-no-perl-seting-change'

The build procedure did not bother fixing perl and python scripts
when NO_PERL and NO_PYTHON build-time configuration changed.

* jk/rebuild-perl-scripts-with-no-perl-seting-change:
  Makefile: have python scripts depend on NO_PYTHON setting
  Makefile: simplify by using SCRIPT_{PERL,SH}_GEN macros
  Makefile: have perl scripts depend on NO_PERL setting

Merge branch 'jk/no-perl-tests'

Some tests that depend on perl lacked PERL prerequisite to protect
them, breaking build with NO_PERL configuration.

* jk/no-perl-tests:
  t960[34]: mark cvsimport tests as requiring perl
  t0090: mark add-interactive test with PERL prerequisite

Merge branch 'sv/typofix-apply-error-message'

* sv/typofix-apply-error-message:
  apply: fix typo in an error message

Merge branch 'po/everyday-doc'

* po/everyday-doc:
  Documentation: change "gitlink" typo in git-push

Merge branch 'mh/config-copy-string-from-git-path'

* mh/config-copy-string-from-git-path:
  cmd_config(): make a copy of path obtained from git_path()

Merge branch 'jc/unpack-trees-plug-leak'

* jc/unpack-trees-plug-leak:
  unpack_trees: plug leakage of o->result

tests: squelch noise from GPG machinery set-up

It is distracting to let the GPG message while setting up the test
gpghome leak into the test output, especially without running these
tests with "-v" option.

The splitting of RFC1991 prerequiste part is about future-proofing.
When we want to define other kinds of specific prerequisites in the
future, we'd prefer to see it done separately from the basic set-up
code.

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

tests: replace binary GPG keyrings with ASCII-armored keys

Importing PGP key public and security ring works, but we do not have
all secret keys in one binary blob and all public keys in another.
Instead import public and secret keys for one key pair from a text
file that holds ASCII-armored export of them.

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

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>