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

* mg/maint-pull-suggest-upstream-to:
  push/pull: adjust missing upstream help text to changed interface

* mm/maint-doc-commit-edit:
  Document 'git commit --no-edit' explicitly

* as/maint-doc-fix-no-post-rewrite:
  commit: fixup misplacement of --no-post-rewrite description

* rs/lock-correct-ref-during-delete:
  refs: lock symref that is to be deleted, not its target

* rf/maint-mailmap-off-by-one:
  mailmap: avoid out-of-bounds memory access

"git diff -G<pattern>" did not honor textconv filter when looking
for changes.

* jk/maint-diff-grep-textconv:
  diff_grep: use textconv buffers for add/deleted files

Various rfc2047 quoting issues around a non-ASCII name on the From:
line in the output from format-patch have been corrected.

* js/format-2047:
  format-patch tests: check quoting/encoding in To: and Cc: headers
  format-patch: fix rfc2047 address encoding with respect to rfc822 specials
  format-patch: make rfc2047 encoding more strict
  format-patch: introduce helper function last_line_length()
  format-patch: do not wrap rfc2047 encoded headers too late
  format-patch: do not wrap non-rfc2047 headers too early
  utf8: fix off-by-one wrapping of text

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

Sometimes curl_multi_timeout() function suggested a wrong timeout
value when there is no file descriptors to wait on and the http
transport ended up sleeping for minutes in select(2) system call.  A
workaround has been added for this.

* sz/maint-curl-multi-timeout:
  Fix potential hang in https handshake

The refs/replace hierarchy was not mentioned in the
repository-layout docs.

* po/maint-refs-replace-docs:
  Doc repository-layout: Show refs/replace

"git pull --rebase" run while the HEAD is detached tried to find
the upstream branch of the detached HEAD (which by definition
does not exist) and emitted unnecessary error messages.

* ph/pull-rebase-detached:
  git-pull: Avoid merge-base on detached head

Update "remote tracking branch" in the documentation to
"remote-tracking branch".

* mm/maint-doc-remote-tracking:
  Documentation: remote tracking branch -> remote-tracking branch

A symbolic ref refs/heads/SYM was not correctly removed with "git
branch -d SYM"; the command removed the ref pointed by SYM instead.

* rs/branch-del-symref:
  branch: show targets of deleted symrefs, not sha1s
  branch: skip commit checks when deleting symref branches
  branch: delete symref branch, not its target
  branch: factor out delete_branch_config()
  branch: factor out check_branch_commit()

"git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.

* nd/grep-true-path:
  grep: stop looking at random places for .gitattributes

"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally.

* 'jc/grep-pcre-loose-ends' (early part):
  log --grep: use the same helper to set -E/-F options as "git grep"
  revisions: initialize revs->grep_filter using grep_init()
  grep: move pattern-type bits support to top-level grep.[ch]
  grep: move the configuration parsing logic to grep.[ch]
  builtin/grep.c: make configuration callback more reusable

"git mergetool" feeds /dev/null as a common ancestor when dealing
with an add/add conflict, but p4merge backend cannot handle it. Work
it around by passing a temporary empty file.

* da/mergetools-p4:
  mergetools/p4merge: Handle "/dev/null"

The "say" function in the test scaffolding incorrectly allowed
"echo" to interpret "\a" as if it were a C-string asking for a BEL
output.

* jc/test-say-color-avoid-echo-escape:
  test-lib: Fix say_color () not to interpret \a\b\c in the message

The configuration parser had an unnecessary hardcoded limit on
variable names that was not checked consistently.

* bw/config-lift-variable-name-length-limit:
  Remove the hard coded length limit on variable names in config files

In case of a missing upstream, the git-parse-remote script suggests:

If you wish to set tracking information for this branch you can do so
with:

    git branch --set-upstream nsiv2 origin/<branch>

But --set-upstream is deprectated. Change the suggestion to:

    git branch --set-upstream-to=origin/<branch> nsiv2
Reported-by: NJeroen van der Ham <vdham@uva.nl>
Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: NJeff King <peff@peff.net>

In e858af6d (commit: document a couple of options) the description of the
--no-post-rewrite option was put inside the paragraph for the --amend
option.  Move it down after the paragraph.
Signed-off-by: NAndreas Schwab <schwab@linux-m68k.org>
Signed-off-by: NJeff King <peff@peff.net>

Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJeff King <peff@peff.net>

If you use "-G" to grep a diff, we will apply a configured
textconv filter to the data before generating the diff.
However, if the diff is an addition or deletion, we do not
bother running the diff at all, and just look for the token
in the added (or removed) content. This works because we
know that the diff must contain every line of content.

However, while we used the textconv-derived buffers in the
regular diff, we accidentally passed the original unmodified
buffers to regexec when checking the added or removed
content. This could lead to an incorrect answer.

Worse, in some cases we might have a textconv buffer but no
original buffer (e.g., if we pulled the textconv data from
cache, or if we reused a working tree file when generating
it). In that case, we could actually feed NULL to regexec
and segfault.
Reported-by: NPeter Oberndorfer <kumbayo84@arcor.de>
Signed-off-by: NJeff King <peff@peff.net>

AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html)
complains of a one-byte buffer underflow in parse_name_and_email() while
running the test suite. And indeed, if one of the lines in the mailmap
begins with '<', we dereference the address just before the beginning of
the buffer when looking for whitespace to remove, before checking that
we aren't going too far.

So reverse the order of the tests to make sure that we don't read
outside the buffer.
Signed-off-by: NRomain Francoise <romain@orebokech.com>
Signed-off-by: NJeff King <peff@peff.net>

Signed-off-by: NPhilip Oakley <philipoakley@iee.org>
Signed-off-by: NJeff King <peff@peff.net>

This change was already done by 0e615b25 (Matthieu Moy, Tue Nov 2
2010, Replace "remote tracking" with "remote-tracking"), but new
instances of remote tracking (without dash) were introduced in the
meantime.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJeff King <peff@peff.net>

git pull --rebase does some clever tricks to find the base
for $upstream, but it forgets that we may not have any
branch at all.  When this happens, git merge-base reports its
"usage" help in the middle of an otherwise successful
rebase operation, because git-merge is called with one too
few parameters.

Since we do not need the merge-base trick in the case of a
detached HEAD, detect this condition and bypass the clever
trick and the usage noise.
Signed-off-by: NPhil Hord <hordp@cisco.com>
Signed-off-by: NJeff King <peff@peff.net>

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

It has been observed that curl_multi_timeout may return a very long
timeout value (e.g., 294 seconds and some usec) just before
curl_multi_fdset returns no file descriptors for reading.  The
upshot is that select() will hang for a long time -- long enough for
an https handshake to be dropped.  The observed behavior is that
the git command will hang at the terminal and never transfer any
data.

This patch is a workaround for a probable bug in libcurl.  The bug
only seems to manifest around a very specific set of circumstances:

- curl version (from curl/curlver.h):

 #define LIBCURL_VERSION_NUM 0x071307

- git-remote-https running on an ubuntu-lucid VM.
- Connecting through squid proxy running on another VM.

Interestingly, the problem doesn't manifest if a host connects
through squid proxy running on localhost; only if the proxy is on
a separate VM (not sure if the squid host needs to be on a separate
physical machine).  That would seem to suggest that this issue
is timing-sensitive.

This patch is more or less in line with a recommendation in the
curl docs about how to behave when curl_multi_fdset doesn't return
and file descriptors:

http://curl.haxx.se/libcurl/c/curl_multi_fdset.htmlSigned-off-by: NStefan Zager <szager@google.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git branch reports the abbreviated hash of the head commit of
a deleted branch to make it easier for a user to undo the
operation.  For symref branches this doesn't help.  Print the
symref target instead for them.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Before a branch is deleted, we check that it points to a valid
commit.  With -d we also check that the commit is a merged; this
check is not done with -D.

The reason for that is that commits pointed to by branches should
never go missing; if they do then something broke and it's better
to stop instead of adding to the mess.  And a non-merged commit
may contain changes that are worth preserving, so we require the
stronger option -D instead of -d to get rid of them.

If a branch consists of a symref, these concerns don't apply.
Deleting such a branch can't make a commit become unreferenced,
so we don't need to check if it is merged, or even if it is
actually a valid commit.  Skip them in that case.  This allows
us to delete dangling symref branches.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If a branch that is to be deleted happens to be a symref to another
branch, the current code removes the targeted branch instead of the
one it was called for.

Change this surprising behaviour and delete the symref branch
instead.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Provide a small helper function for deleting branch config sections.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Move the code to perform checks on the tip commit of a branch
to its own function.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-format-patch does currently not parse user supplied extra header
values (e. g., --cc, --add-header) and just replays them. That forces
users to add them RFC 2822/2047 conform in encoded form, e.g.

    --cc '=?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr?= <...>'

which is inconvenient. We would want to update git-format-patch to
accept human-readable input

    --cc 'Jan H. Schönherr <...>'

and handle the encoding, wrapping and quoting internally in the future,
similar to what is already done in git-send-email. The necessary code
should mostly exist in the code paths that handle the From: and Subject:
headers.

Whether we want to do this only for the git-format-patch options
--to and --cc (and the corresponding config options) or also for
user supplied headers via --add-header, is open for discussion.

For now, add test_expect_failure tests for To: and Cc: headers as a
reminder and fix tests that would otherwise fail should this get
implemented.
Signed-off-by: NJan H. Schönherr <schnhrr@cs.tu-berlin.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

According to RFC 2047 and RFC 822, rfc2047 encoded words and and rfc822
quoted strings do not mix. Since add_rfc2047() no longer leaves RFC 822
specials behind, the quoting is also no longer necessary to create a
standard-conforming mail.

Remove the quoting, when RFC 2047 encoding takes place. This actually
requires to refactor add_rfc2047() a bit, so that the different cases
can be distinguished.

With this patch, my own name gets correctly decoded as Jan H. Schönherr
(without quotes) and not as "Jan H. Schönherr" (with quotes).
Signed-off-by: NJan H. Schönherr <schnhrr@cs.tu-berlin.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

RFC 2047 requires more characters to be encoded than it is currently done.
Especially, RFC 2047 distinguishes between allowed remaining characters
in encoded words in addresses (From, To, etc.) and other headers, such
as Subject.

Make add_rfc2047() and is_rfc2047_special() location dependent and include
all non-allowed characters to hopefully be RFC 2047 conformant.

This especially fixes a problem, where RFC 822 specials (e. g. ".") were
left unencoded in addresses, which was solved with a non-standard-conforming
workaround in the past (which is going to be removed in a follow-up patch).
Signed-off-by: NJan H. Schönherr <schnhrr@cs.tu-berlin.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently, an open-coded loop to calculate the length of the last
line of a string buffer is used in multiple places.

Move that code into a function of its own.
Signed-off-by: NJan H. Schönherr <schnhrr@cs.tu-berlin.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Encoded characters add more than one character at once to an encoded
header. Include all characters that are about to be added in the length
calculation for wrapping.

Additionally, RFC 2047 imposes a maximum line length of 76 characters
if that line contains an rfc2047 encoded word.
Signed-off-by: NJan H. Schönherr <schnhrr@cs.tu-berlin.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Do not wrap the second and later lines of non-rfc2047-encoded headers
substantially before the 78 character limit.

Instead of passing the remaining length of the first line as wrapping
width, use the correct maximum length and tell strbuf_add_wrapped_bytes()
how many characters of the first line are already used.
Signed-off-by: NJan H. Schönherr <schnhrr@cs.tu-berlin.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>