Git.pm: add interface for git credential command

Add a credential() function which is an interface to the git
credential command.  The code is heavily based on credential_*
functions in <contrib/mw-to-git/git-remote-mediawiki>.

Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-send-email: use git credential to obtain password

If smtp_user is provided but smtp_pass is not, instead of
prompting for password, make git-send-email use git
credential command instead.

Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mh/maint-ceil-absolute'

An earlier workaround designed to help people who list logical
directories that will not match what getcwd(3) returns in the
GIT_CEILING_DIRECTORIES had an adverse effect when it is slow to
stat and readlink a directory component of an element listed on it.

* mh/maint-ceil-absolute:
  Provide a mechanism to turn off symlink resolution in ceiling paths
Merge branch 'jn/less-reconfigure' into maint

* jn/less-reconfigure:
  Makefile: avoid infinite loop on configure.ac change
Merge branch 'wk/man-deny-current-branch-is-default-these-days' into maint

* wk/man-deny-current-branch-is-default-these-days:
  user-manual: typofix (ofthe->of the)
  user-manual: Update for receive.denyCurrentBranch=refuse
Merge branch 'ef/non-ascii-parse-options-error-diag' into maint

* ef/non-ascii-parse-options-error-diag:
  parse-options: report uncorrupted multi-byte options
Update draft release notes to 1.8.1.5

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'

* maint:
  Update draft release notes to 1.8.1.5
  Documentation/submodule: Add --force to update synopsis
name-hash.c: fix endless loop with core.ignorecase=true

With core.ignorecase=true, name-hash.c builds a case insensitive index of
all tracked directories. Currently, the existing cache entry structures are
added multiple times to the same hashtable (with different name lengths and
hash codes). However, there's only one dir_next pointer, which gets
completely messed up in case of hash collisions. In the worst case, this
causes an endless loop if ce == ce->dir_next (see t7062).

Use a separate hashtable and separate structures for the directory index
so that each directory entry has its own next pointer. Use reference
counting to track which directory entry contains files.

There are only slight changes to the name-hash.c API:
- new free_name_hash() used by read_cache.c::discard_index()
- remove_name_hash() takes an additional index_state parameter
- index_name_exists() for a directory (trailing '/') may return a cache
  entry that has been removed (CE_UNHASHED). This is not a problem as the
  return value is only used to check if the directory exists (dir.c) or to
  normalize casing of directory names (read-cache.c).

Getting rid of cache_entry.dir_next reduces memory consumption, especially
with core.ignorecase=false (which doesn't use that member at all).

With core.ignorecase=true, building the directory index is slightly faster
as we add / check the parent directory first (instead of going through all
directory levels for each file in the index). E.g. with WebKit (~200k
files, ~7k dirs), time spent in lazy_init_name_hash is reduced from 176ms
to 130ms.

Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
describe: --match=<pattern> must limit the refs even when used with --all

The logic to limit the refs used for describing with a matching pattern
with --match=<pattern> parameter was implemented incorrectly when --all
is in effect.  It just demoted a ref that did not match the pattern to
lower priority---if there aren't other refs with higher priority
that describe the given commit, such an unmatching ref was still used.

When --match is used, reject refs that do not match the given
criteria, so that with or without --all, the output will only use
refs that match the pattern.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/githooks: Fix linkgit

Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'wk/user-manual' into maint

* wk/user-manual:
  user-manual: Flesh out uncommitted changes and submodule updates
  user-manual: Use request-pull to generate "please pull" text
  user-manual: Reorganize the reroll sections, adding 'git rebase -i'
Make !pattern in .gitattributes non-fatal

Before 82dce99 (attr: more matching optimizations from .gitignore,
2012-10-15), .gitattributes did not have any special treatment of a
leading '!'.  The docs, however, always said

  The rules how the pattern matches paths are the same as in
  `.gitignore` files; see linkgit:gitignore[5].

By those rules, leading '!' means pattern negation.  So 82dce99
correctly determined that this kind of line makes no sense and should
be disallowed.

However, users who actually had a rule for files starting with a '!'
are in a bad position: before 82dce99 '!' matched that literal
character, so it is conceivable that users have .gitattributes with
such lines in them.  After 82dce99 the unescaped version was
disallowed in such a way that git outright refuses to run(!) most
commands in the presence of such a .gitattributes.  It therefore
becomes very hard to fix, let alone work with, such repositories.

Let's at least allow the users to fix their repos: change the fatal
error into a warning.

Reported-by: mathstuf@gmail.com
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git 1.8.1.5

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sync with 1.8.1.5
mailsplit: sort maildir filenames more cleverly

A maildir does not technically record the order in which
items were placed into it. That means that when applying a
patch series from a maildir, we may get the patches in the
wrong order. We try to work around this by sorting the
filenames. Unfortunately, this may or may not work depending
on the naming scheme used by the writer of the maildir.

For instance, mutt will write:

  ${epoch_seconds}.${pid}_${seq}.${host}

where we have:

  - epoch_seconds: timestamp at which entry was written
  - pid: PID of writing process
  - seq: a sequence number to ensure uniqueness of filenames
  - host: hostname

None of the numbers are zero-padded. Therefore, when we sort
the names as byte strings, entries that cross a digit
boundary (e.g., 10) will sort out of order.  In the case of
timestamps, it almost never matters (because we do not cross
a digit boundary in the epoch time very often these days).
But for the sequence number, a 10-patch series would be
ordered as 1, 10, 2, 3, etc.

To fix this, we can use a custom sort comparison function
which traverses each string, comparing chunks of digits
numerically, and otherwise doing a byte-for-byte comparison.
That would sort:

  123.456_1.bar
  123.456_2.bar
  ...
  123.456_10.bar

according to the sequence number. Since maildir does not
define a filename format, this is really just a heuristic.
But it happens to work for mutt, and there is a reasonable
chance that it will work for other writers, too (at least as
well as a straight sort).

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

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revert "graph.c: mark private file-scope symbols as static"

This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb.

CGit uses these symbols to output the correct HTML around graph
elements.  Making these symbols private means that CGit cannot be
updated to use Git 1.8.0 or newer, so let's not do that.

On top of the revert, also add comments so that we avoid reintroducing
this problem in the future and suggest to those modifying this API
that they might want to discuss it with the CGit developers.

Signed-off-by: John Keeping <john@keeping.me.uk>
Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule update: when using recursion, show full path

Previously when using update with recursion, only the path for the
inner-most module was printed. Now the path is printed relative to
the directory the command was started from. This now matches the
behavior of submodule foreach.

Signed-off-by: William Entriken <github.com@phor.net>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
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: correct translation of "bisect" messages
  l10n: de.po: translate 5 new messages
  l10n: de.po: translate 35 new messages