http-push: trim trailing newline from remote symref

When we fetch a symbolic ref file from the remote, we get
the whole string "ref: refs/heads/master\n", recognize it by
skipping past the "ref: ", and store the rest. We should
chomp the trailing newline.

This bug was introduced in ae021d8 (use skip_prefix to avoid
magic numbers, 2014-06-18), which did not notice that the
length computation fed to xmemdupz was quietly tweaked by 1
to account for this.

We can solve it by explicitly trimming the newline, which is
more obvious. Note that we use strbuf_rtrim here, which will
actually cut off any trailing whitespace, not just a single
newline. This is a good thing, though, as it makes our
parsing more liberal (and spaces are not valid in refnames
anyway).

Signed-off-by: Jeff King <peff@peff.net>
Tested-by: Kyle J. McKay <mackyle@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint-2.0' into maint-2.1

* maint-2.0:
  is_hfs_dotgit: loosen over-eager match of \u{..47}

Merge branch 'maint-1.9' into maint-2.0

* maint-1.9:
  is_hfs_dotgit: loosen over-eager match of \u{..47}

Merge branch 'maint-1.8.5' into maint-1.9

* maint-1.8.5:
  is_hfs_dotgit: loosen over-eager match of \u{..47}

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

* jk/dotgit-case-maint-1.8.5:
  is_hfs_dotgit: loosen over-eager match of \u{..47}

is_hfs_dotgit: loosen over-eager match of \u{..47}

Our is_hfs_dotgit function relies on the hackily-implemented
next_hfs_char to give us the next character that an HFS+
filename comparison would look at. It's hacky because it
doesn't implement the full case-folding table of HFS+; it
gives us just enough to see if the path matches ".git".

At the end of next_hfs_char, we use tolower() to convert our
32-bit code point to lowercase. Our tolower() implementation
only takes an 8-bit char, though; it throws away the upper
24 bits. This means we can't have any false negatives for
is_hfs_dotgit. We only care about matching 7-bit ASCII
characters in ".git", and we will correctly process 'G' or
'g'.

However, we _can_ have false positives. Because we throw
away the upper bits, code point \u{0147} (for example) will
look like 'G' and get downcased to 'g'. It's not known
whether a sequence of code points whose truncation ends up
as ".git" is meaningful in any language, but it does not
hurt to be more accurate here. We can just pass out the full
32-bit code point, and compare it manually to the upper and
lowercase characters we care about.

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

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>

Merge branch 'nd/gitignore-trailing-whitespace' into maint

* nd/gitignore-trailing-whitespace:
  gitignore.txt: fix spelling of "backslash"

Merge branch 'rs/clean-menu-item-defn' into maint

* rs/clean-menu-item-defn:
  clean: use f(void) instead of f() to declare a pointer to a function without arguments

Documentation/config.txt: fix minor typo

Add a missing article at the beginning of a sentence, and rephrase
slightly.

Signed-off-by: Thomas Quinot <thomas@quinot.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config.txt: fix typo

Signed-off-by: Nicolas Dermine <nicolas.dermine@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

docs/credential-store: s/--store/--file/

The option name "--store" was used early in development, but
never even made it into an applied patch, let alone a
released version of git. I forgot to update the matching
documentation at the time, though.

Noticed-by: Jesse Hopkins <jesse.hopkins@lmco.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitignore.txt: fix spelling of "backslash"

Signed-off-by: Ben North <ben@redfrontdoor.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Git 2.1.3

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

Merge branch 'jk/pack-objects-no-bitmap-when-splitting' into maint

* jk/pack-objects-no-bitmap-when-splitting:
  pack-objects: turn off bitmaps when we split packs

Merge branch 'da/mergetool-meld' into maint

* da/mergetool-meld:
  mergetools/meld: make usage of `--output` configurable and more robust

Merge branch 'rm/gitweb-start-form' into maint

* rm/gitweb-start-form:
  gitweb: use start_form, not startform that was removed in CGI.pm 4.04

Merge branch 'bc/asciidoc-pretty-formats-fix' into maint

* bc/asciidoc-pretty-formats-fix:
  Documentation: fix misrender of pretty-formats in Asciidoctor

Merge branch 'rs/daemon-fixes' into maint

* rs/daemon-fixes:
  daemon: remove write-only variable maxfd
  daemon: fix error message after bind()
  daemon: handle gethostbyname() error

pack-objects: turn off bitmaps when we split packs

If a pack.packSizeLimit is set, we may split the pack data
across multiple packfiles. This means we cannot generate
.bitmap files, as they require that all of the reachable
objects are in the same pack. We check that condition when
we are generating the list of objects to pack (and disable
bitmaps if we are not packing everything), but we forgot to
update it when we notice that we needed to split (which
doesn't happen until the actual write phase).

The resulting bitmaps are quite bogus (they mention entries
that do not exist in the pack!) and can cause a fetch or
push to send insufficient objects.

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

gitweb: use start_form, not startform that was removed in CGI.pm 4.04

CGI.pm 4.04 removed the startform method, which had previously been
deprecated in favour of start_form.  Changes file for CGI.pm says:

    4.04 2014-09-04
     [ REMOVED / DEPRECATIONS ]
- startform and endform methods removed (previously deprecated,
  you should be using the start_form and end_form methods)

Signed-off-by: Roland Mas <lolando@debian.org>
Reviewed-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mergetools/meld: make usage of `--output` configurable and more robust

Older versions of meld listed --output in `meld --help`.
Newer versions only mention `meld [OPTIONS...]`.
Improve the checks to catch these newer versions.

Add a `mergetool.meld.hasOutput` configuration to allow
overriding the heuristic.

Reported-by: Andrey Novoseltsev <novoselt@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: fix misrender of pretty-formats in Asciidoctor

Neither the AsciiDoc nor the Asciidoctor documentation specify whether
the same number of delimiter characters must be used to end a block as
to begin it, although both sets of documentation show exactly matching
pairs.  AsciiDoc allows mismatches, but AsciiDoctor apparently does not.
Adjust the pretty formats documentation to use matching pairs to prevent
a misrendering where the remainder of the document was rendered as a
listing block.

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

Merge branch 'maint-2.0' into maint

* maint-2.0:
  git-tag.txt: Add a missing hyphen to `-s`

Merge branch 'maint-1.9' into maint-2.0

* maint-1.9:
  git-tag.txt: Add a missing hyphen to `-s`

Merge branch 'maint-1.8.5' into maint-1.9

* maint-1.8.5:
  git-tag.txt: Add a missing hyphen to `-s`

Merge branch 'jk/mbox-from-line' into maint

Some MUAs mangled a line in a message that begins with "From " to
">From " when writing to a mailbox file and feeding such an input to
"git am" used to lose such a line.

* jk/mbox-from-line:
  mailinfo: work around -Wstring-plus-int warning
  mailinfo: make ">From" in-body header check more robust

git-tag.txt: Add a missing hyphen to `-s`

Signed-off-by: Wieland Hoffmann <themineo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

daemon: remove write-only variable maxfd

It became unused when 6573faff (NO_IPV6 support for git daemon) replaced
select() with poll().

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

daemon: fix error message after bind()

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

daemon: handle gethostbyname() error

If the user-supplied hostname can't be found then we should not use it.
We already avoid doing that in the non-NO_IPV6 case by checking if the
return value of getaddrinfo() is zero (success).  Do the same in the
NO_IPV6 case and make sure the return value of gethostbyname() isn't
NULL before dereferencing this pointer.

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

Git 2.1.2

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

Merge branch 'jk/fsck-exit-code-fix' into maint

"git fsck" failed to report that it found corrupt objects via its
exit status in some cases.

* jk/fsck-exit-code-fix:
  fsck: return non-zero status on missing ref tips
  fsck: exit with non-zero status upon error from fsck_obj()

Merge branch 'ta/config-add-to-empty-or-true-fix' into maint

"git config --add section.var val" used to lose existing
section.var whose value was an empty string.

* ta/config-add-to-empty-or-true-fix:
  config: avoid a funny sentinel value "a^"
  make config --add behave correctly for empty and NULL values

Merge branch 'mk/reachable-protect-detached-head' into maint

Reachability check (used in "git prune" and friends) did not add a
detached HEAD as a starting point to traverse objects still in use.

* mk/reachable-protect-detached-head:
  reachable.c: add HEAD to reachability starting commits

Merge branch 'mb/fast-import-delete-root' into maint

An attempt to remove the entire tree in the "git fast-import" input
stream caused it to misbehave.

* mb/fast-import-delete-root:
  fast-import: fix segfault in store_tree()
  t9300: test filedelete command

Merge branch 'jk/index-pack-threading-races' into maint

When receiving an invalid pack stream that records the same object
twice, multiple threads got confused due to a race.

* jk/index-pack-threading-races:
  index-pack: fix race condition with duplicate bases

Merge branch 'jk/send-pack-many-refspecs' into maint

"git push" over HTTP transport had an artificial limit on number of
refs that can be pushed imposed by the command line length.

* jk/send-pack-many-refspecs:
  send-pack: take refspecs over stdin

Merge branch 'so/rebase-doc' into maint

* so/rebase-doc:
  Documentation/git-rebase.txt: <upstream> must be given to specify <branch>
  Documentation/git-rebase.txt: -f forces a rebase that would otherwise be a no-op

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: use comma before "um"
  l10n: de.po: change Email to E-Mail
  po/TEAMS: add new member to German translation team

l10n: de.po: use comma before "um"

This patch adds a comma before the "um". See:
http://www.duden.de/sprachwissen/rechtschreibregeln/komma#K117

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

l10n: de.po: change Email to E-Mail

Change all Email to E-Mail, as this is the correct form in German.

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

po/TEAMS: add new member to German translation team

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

mailinfo: work around -Wstring-plus-int warning

The just-released Apple Xcode 6.0.1 has -Wstring-plus-int enabled by
default which complains about pointer arithmetic applied to a string
literal:

    builtin/mailinfo.c:303:24: warning:
        adding 'long' to a string does not append to the string
            return !memcmp(SAMPLE + (cp - line), cp, strlen(SAMPLE) ...
                           ~~~~~~~^~~~~~~~~~~~~

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

Git 2.1.1

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

Merge branch 'et/spell-poll-infinite-with-minus-one-only' into maint

* et/spell-poll-infinite-with-minus-one-only:
  upload-pack: keep poll(2)'s timeout to -1

Merge branch 'nd/fetch-pass-quiet-to-gc-child-process' into maint

* nd/fetch-pass-quiet-to-gc-child-process:
  fetch: silence git-gc if --quiet is given
  fetch: convert argv_gc_auto to struct argv_array

Merge branch 'jk/prune-top-level-refs-after-packing' into maint

* jk/prune-top-level-refs-after-packing:
  pack-refs: prune top-level refs like "refs/foo"

Merge branch 'jk/fast-import-fixes' into maint

* jk/fast-import-fixes:
  fast-import: fix buffer overflow in dump_tags
  fast-import: clean up pack_data pointer in end_packfile

Merge branch 'jn/unpack-trees-checkout-m-carry-deletion' into maint

* jn/unpack-trees-checkout-m-carry-deletion:
  checkout -m: attempt merge when deletion of path was staged
  unpack-trees: use 'cuddled' style for if-else cascade
  unpack-trees: simplify 'all other failures' case

Merge branch 'sp/pack-protocol-doc-on-shallow' into maint

* sp/pack-protocol-doc-on-shallow:
  Document LF appearing in shallow command during send-pack/receive-pack

Merge branch 'jk/prompt-stash-could-be-packed' into maint

* jk/prompt-stash-could-be-packed:
  git-prompt: do not look for refs/stash in $GIT_DIR

Merge branch 'rs/refresh-beyond-symlink' into maint

* rs/refresh-beyond-symlink:
  read-cache: check for leading symlinks when refreshing index

Merge branch 'lf/bundle-exclusion' into maint

* lf/bundle-exclusion:
  bundle: fix exclusion of annotated tags

Merge branch 'jc/apply-ws-prefix' into maint

* jc/apply-ws-prefix:
  apply: omit ws check for excluded paths
  apply: hoist use_patch() helper for path exclusion up
  apply: use the right attribute for paths in non-Git patches

Conflicts:
builtin/apply.c

Merge branch 'jk/command-line-config-empty-string' into maint

* jk/command-line-config-empty-string:
  config: teach "git -c" to recognize an empty string

Conflicts:
config.c

Merge branch 'jk/pretty-empty-format' into maint

* jk/pretty-empty-format:
  pretty: make empty userformats truly empty
  pretty: treat "--format=" as an empty userformat
  revision: drop useless string offset when parsing "--pretty"

Documentation/git-rebase.txt: <upstream> must be given to specify <branch>

Current syntax description makes one wonder if there is any
syntactic way to distinguish between <branch> and <upstream> so that
one can specify <branch> but not <upstream>, but that is not the
case.

Make it explicit that these arguments are positional, i.e. the
earlier ones cannot be omitted if you want to give later ones.

Signed-off-by: Sergey Organov <sorganov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mailinfo: make ">From" in-body header check more robust

Since commit 81c5cf7 (mailinfo: skip bogus UNIX From line inside
body, 2006-05-21), we have treated lines like ">From" in the body as
headers. This makes "git am" work for people who erroneously paste
the whole output from format-patch:

  From 12345abcd...fedcba543210 Mon Sep 17 00:00:00 2001
  From: them
  Subject: [PATCH] whatever

into their email body (assuming that an mbox writer then quotes
"From" as ">From", as otherwise we would actually mailsplit on the
in-body line).

However, this has false positives if somebody actually has a commit
body that starts with "From "; in this case we erroneously remove
the line entirely from the commit message. We can make this check
more robust by making sure the line actually looks like a real mbox
"From" line.

Inspect the line that begins with ">From " a more carefully to only
skip lines that match the expected pattern (note that the datestamp
part of the format-patch output is designed to be kept constant to
help those who write magic(5) entries).

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

fsck: return non-zero status on missing ref tips

Fsck tries hard to detect missing objects, and will complain
(and exit non-zero) about any inter-object links that are
missing. However, it will not exit non-zero for any missing
ref tips, meaning that a severely broken repository may
still pass "git fsck && echo ok".

The problem is that we use for_each_ref to iterate over the
ref tips, which hides broken tips. It does at least print an
error from the refs.c code, but fsck does not ever see the
ref and cannot note the problem in its exit code. We can solve
this by using for_each_rawref and noting the error ourselves.

In addition to adding tests for this case, we add tests for
all types of missing-object links (all of which worked, but
which we were not testing).

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

config: avoid a funny sentinel value "a^"

Introduce CONFIG_REGEX_NONE as a more explicit sentinel value to say
"we do not want to replace any existing entry" and use it in the
implementation of "git config --add".

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

fsck: exit with non-zero status upon error from fsck_obj()

Upon finding a corrupt loose object, we forgot to note the error to
signal it with the exit status of the entire process.

[jc: adjusted t1450 and added another test]

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

reachable.c: add HEAD to reachability starting commits

HEAD is not explicitly used as a starting commit for
calculating reachability, so if it's detached and reflogs
are disabled it may be pruned.

Add tests which demonstrate it. Test 'prune: prune former HEAD after checking
out branch' also reverts changes to repository.

Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

index-pack: fix race condition with duplicate bases

When we are resolving deltas in an indexed pack, we do it by
first selecting a potential base (either one stored in full
in the pack, or one created by resolving another delta), and
then resolving any deltas that use that base.  When we
resolve a particular delta, we flip its "real_type" field
from OBJ_{REF,OFS}_DELTA to whatever the real type is.

We assume that traversing the objects this way will visit
each delta only once. This is correct for most packs; we
visit the delta only when we process its base, and each
object (and thus each base) appears only once. However, if a
base object appears multiple times in the pack, we will try
to resolve any deltas based on it once for each instance.

We can detect this case by noting that a delta we are about
to resolve has already had its real_type field flipped, and
we already do so with an assert().  However, if multiple
threads are in use, we may race with another thread on
comparing and flipping the field. We need to synchronize the
access.

The right mechanism for doing this is a compare-and-swap (we
atomically "claim" the delta for our own and find out
whether our claim was successful). We can implement this
in C by using a pthread mutex to protect the operation. This
is not the fastest way of doing a compare-and-swap; many
processors provide instructions for this, and gcc and other
compilers provide builtins to access them. However, some
experiments showed that lock contention does not cause a
significant slowdown here. Adding c-a-s support for many
compilers would increase the maintenance burden (and we
would still end up including the pthread version as a
fallback).

Note that we only need to touch the OBJ_REF_DELTA codepath
here. An OBJ_OFS_DELTA object points to its base using an
offset, and therefore has only one base, even if another
copy of that base object appears in the pack (we do still
touch it briefly because the setting of real_type is
factored out of resolve_data).

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

fast-import: fix segfault in store_tree()

Branch tree is NULLified by filedelete command if we are trying
to delete root tree. Add sanity check and use load_tree() in that case.

Signed-off-by: Maxim Bublis <satori@yandex-team.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t9300: test filedelete command

Add new fast-import test series for filedelete command.

Signed-off-by: Maxim Bublis <satori@yandex-team.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

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

* git://github.com/git-l10n/git-po:
  po/TEAMS: add new members to German translation team
  l10n: de.po: translate 38 new messages

po/TEAMS: add new members to German translation team

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

l10n: de.po: translate 38 new messages

Translate 38 new messages came from git.pot update in fe05e19
(l10n: git.pot: v2.1.0 round 1 (38 new, 9 removed)).

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

Document LF appearing in shallow command during send-pack/receive-pack

The implementation sends an LF, but the protocol documentation was
missing this detail.

Signed-off-by: Shawn Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

send-pack: take refspecs over stdin

Pushing a large number of refs works over most transports,
because we implement send-pack as an internal function.
However, it can sometimes fail when pushing over http,
because we have to spawn "git send-pack --stateless-rpc" to
do the heavy lifting, and we pass each refspec on the
command line. This can cause us to overflow the OS limits on
the size of the command line for a large push.

We can solve this by giving send-pack a --stdin option and
using it from remote-curl.  We already dealt with this on
the fetch-pack side in 078b895 (fetch-pack: new --stdin
option to read refs from stdin, 2012-04-02). The stdin
option (and in particular, its use of packet-lines for
stateless-rpc input) is modeled after that solution.

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

Merge branch 'jk/diff-tree-t-fix'

Fix (rarely used) "git diff-tree -t" regression in 2.0.

* jk/diff-tree-t-fix:
  intersect_paths: respect mode in git's tree-sort

Merge branch 'jk/pack-shallow-always-without-bitmap'

Reachability bitmaps do not work with shallow operations.
Fixes regression in 2.0.

* jk/pack-shallow-always-without-bitmap:
  pack-objects: turn off bitmaps when we see --shallow lines

Merge branch 'jk/fix-profile-feedback-build'

Fix profile-feedback build broken in 2.1 for tarball releases.

* jk/fix-profile-feedback-build:
  Makefile: make perf tests optional for profile build

checkout -m: attempt merge when deletion of path was staged

twoway_merge() is missing an o->gently check in the case where a file
that needs to be modified is missing from the index but present in the
old and new trees.  As a result, in this case 'git checkout -m' errors
out instead of trying to perform a merge.

Fix it by checking o->gently.  While at it, inline the o->gently check
into reject_merge to prevent future call sites from making the same
mistake.

Noticed by code inspection.  The test for the motivating case was
added by JC.

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

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

* git://github.com/git-l10n/git-po:
  l10n: de.po: improve message when switching branches
  l10n: de.po: fix typo
  po/TEAMS: Add Catalan team
  l10n: Add Catalan translation
  l10n: fr.po (2257t) update for version 2.1.0
  l10n: sv.po: Update Swedish translation (2257t0f0u)
  l10n: vi.po (2257t): Update translation
  l10n: Updated Bulgarian translation of git (2257t,0f,0u)
  l10n: zh_CN: translations for git v2.1.0-rc0
  l10n: git.pot: v2.1.0 round 1 (38 new, 9 removed)
  l10n: Updated Bulgarian translation of git (2247t,0f,0u)
  l10n: Updated Bulgarian translation of git (2228t,0f,0u)
  l10n: Fix more typos in the Swedish translations

git-prompt: do not look for refs/stash in $GIT_DIR

Since dd0b72c (bash prompt: use bash builtins to check stash
state, 2011-04-01), git-prompt checks whether we have a
stash by looking for $GIT_DIR/refs/stash. Generally external
programs should never do this, because they would miss
packed-refs.

That commit claims that packed-refs does not pack
refs/stash, but that is not quite true. It does pack the
ref, but due to a bug, fails to prune the ref. When we fix
that bug, we would want to be doing the right thing here.

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

fast-import: fix buffer overflow in dump_tags

When creating a new annotated tag, we sprintf the refname
into a static-sized buffer. If we have an absurdly long
tagname, like:

  git init repo &&
  cd repo &&
  git commit --allow-empty -m foo &&
  git tag -m message mytag &&
  git fast-export mytag |
  perl -lpe '/^tag/ and s/mytag/"a" x 8192/e' |
  git fast-import <input

we'll overflow the buffer. We can fix it by using a strbuf.

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

fast-import: clean up pack_data pointer in end_packfile

We have a global pointer pack_data pointing to the current
pack we have open. Inside end_packfile we have two new
pointers, old_p and new_p. The latter points to pack_data,
and the former points to the new "installed" version of the
packfile we get when we hand the file off to the regular
sha1_file machinery. When then free old_p.

Presumably the extra old_p pointer was there so that we
could overwrite pack_data with new_p and still free old_p,
but we don't do that. We just leave pack_data pointing to
bogus memory, and don't overwrite it until we call
start_packfile again (if ever).

This can cause problems for our die routine, which calls
end_packfile to clean things up. If we die at the wrong
moment, we can end up looking at invalid memory in
pack_data left after the last end_packfile().

Instead, let's make sure we set pack_data to NULL after we
free it, and make calling endfile() again with a NULL
pack_data a noop (there is nothing to end).

We can further make things less confusing by dropping old_p
entirely, and moving new_p closer to its point of use.

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

pack-refs: prune top-level refs like "refs/foo"

After we have packed all refs, we prune any loose refs that
correspond to what we packed. We do so by first taking a
lock with lock_ref_sha1, and then deleting the loose ref
file.

However, lock_ref_sha1 will refuse to take a lock on any
refs that exist at the top-level of the "refs/" directory,
and we skip pruning the ref.  This is almost certainly not
what we want to happen here. The criteria to be pruned
should not differ from that to be packed; if a ref makes it
to prune_ref, it's because we want it both packed and
pruned (if there are refs you do not want to be packed, they
should be omitted much earlier by pack_ref_is_possible,
which we do in this case if --all is not given).

We can fix this by switching to lock_any_ref_for_update.
This behaves exactly the same with the exception of this
top-level check.

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

l10n: de.po: improve message when switching branches

Suggested-by: Stefan Beller <stefanbeller@gmail.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>

l10n: de.po: fix typo

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