merge-one-file: force content conflict for "both sides added" case

Historically, we tried to be lenient to "both sides added, slightly
differently" case and as long as the files can be merged using a
made-up common ancestor cleanly, since f7d24bbefb06 (merge with
/dev/null as base, instead of punting O==empty case, 2005-11-07).

This was later further refined to use a better made-up common file
with fd66dbf5297a (merge-one-file: use empty- or common-base
condintionally in two-stage merge., 2005-11-10), but the spirit has
been the same.

But the original fix in f7d24bbefb06 to avoid punting on "both sides
added" case had a code to unconditionally error out the merge.  When
this triggers, even though the content-level merge can be done
cleanly, we end up not saying "content conflict" in the message, but
still issue the error message, showing "ERROR: in <pathname>".

Move that "always fail for add/add conflict" logic a bit higher to
fix this.

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

git-merge-one-file: send "ERROR:" messages to stderr

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-merge-one-file: style cleanup

Update style to match Documentation/CodingGuidelines.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-one-file: remove stale comment

The "funny filename" comment was from b539c5e8fbd3 (git-merge-one:
new merge world order., 2005-12-07) where the removed code just
before that new comment ended with:

        merge "$4" "$orig" "$src2"

(yes, we used to use "merge" program from the RCS suite).  The
comment refers to one of the bad side effect the old code used to
have and warns against such a practice, i.e. it was talking about
the code that no longer existed.

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

mergetools/p4merge: create a base if none available

Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:

   p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"

Commit 0a0ec7bd changed this to:

   p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED"

to avoid the problem of being unable to save in some circumstances with
similar inputs.

Unfortunately this approach produces much worse results on differing
inputs. P4Merge really regards the blank file as the base, and once you
have just a couple of differences between the two branches you end up
with one a massive full-file conflict. The 3-way diff is not readable,
and you have to invoke "difftool MERGE_HEAD HEAD" manually to get a
useful view.

The original approach appears to have invoked special 2-way merge
behaviour in P4Merge that occurs only if the base filename is "" or
equal to the left input.  You get a good visual comparison, and it does
not auto-resolve differences. (Normally if one branch matched the base,
it would autoresolve to the other branch).

But there appears to be no way of getting this 2-way behaviour and being
able to reliably save. Having base==left appears to be triggering other
assumptions. There are tricks the user can use to force the save icon
on, but it's not intuitive.

So we now follow a suggestion given in the original patch's discussion:
generate a virtual base, consisting of the lines common to the two
branches. This is the same as the technique used in resolve and octopus
merges, so we relocate that code to a shared function.

Note that if there are no differences at the same location, this
technique can lead to automatic resolution without conflict, combining
everything from the 2 files.  As with the other merges using this
technique, we assume the user will inspect the result before saving.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Reviewed-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

mergetools/p4merge: swap LOCAL and REMOTE

Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.

This change makes use of P4Merge consistent with its built-in help, its
reference documentation, and Perforce itself. But most importantly, it
makes merge results clearer. P4Merge is not totally symmetrical between
left and right; despite changing a few text labels from "theirs/ours" to
"left/right" when invoked manually, it still retains its original
Perforce "theirs/ours" viewpoint.

Most obviously, in the result pane P4Merge shows changes that are common
to both branches in green. This is on the basis of the current branch
being green, as it is when invoked from Perforce; it means that lines in
the result are blue if and only if they are being changed by the merge,
making the resulting diff clearer.

Note that P4Merge now shows "ours" on the right for both diff and merge,
unlike other diff/mergetools, which always have REMOTE on the right.
But observe that REMOTE is the working tree (ie "ours") for a diff,
while it's another branch (ie "theirs") for a merge.

Ours and theirs are reversed for a rebase - see "git help rebase".
However, this does produce the desired "show the results of this commit"
effect in P4Merge - changes that remain in the rebased commit (in your
branch, but not in the new base) appear in blue; changes that do not
appear in the rebased commit (from the new base, or common to both) are
in green. If Perforce had rebase, they'd probably not swap ours/theirs,
but make P4Merge show common changes in blue, picking out our changes in
green. We can't do that, so this is next best.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Reviewed-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  perf: update documentation of GIT_PERF_REPEAT_COUNT

perf: update documentation of GIT_PERF_REPEAT_COUNT

Currently the documentation of GIT_PERF_REPEAT_COUNT says the default is
five while "perf-lib.sh" uses a value of three as a default.

Update the documentation so that it is consistent with the code.

Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge git://git.bogomips.org/git-svn

* git://git.bogomips.org/git-svn:
  git svn: consistent spacing after "W:" in warnings
  git svn: ignore partial svn:mergeinfo

Update draft release notes to 1.8.2

Split the backward-compatibility notes into two sections, the ones
that affect this release, and the other to describe changes meant
for Git 2.0.  The latter gives a context to understand why the
changes for this release is necessary.

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

git svn: consistent spacing after "W:" in warnings

All other instances of "W:"-prefixed warning messages have a space after
the "W:" to help with readability.

Signed-off-by: Eric Wong <normalperson@yhbt.net>

git svn: ignore partial svn:mergeinfo

Currently this is cosmetic change - the merges are ignored, becuase the methods
(lookup_svn_merge, find_rev_before, find_rev_after) are failing on comparing text with number.

See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was added to 1.5.x in this merge has a '*' suffix for 1.5.x\www.
This '*' is the marker for a non-inheritable mergeinfo range.
The '*' means that only the path on which the mergeinfo is explicitly set has had this range merged into it.

Signed-off-by: Jan Pesta <jan.pesta@certicon.cz>
Signed-off-by: Eric Wong <normalperson@yhbt.net>

Git 1.8.2-rc3

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

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

* 'master' of git://github.com/git-l10n/git-po:
  l10n: zh_CN.po: translate 1 new message
  l10n: de.po: translate 1 new message
  l10n: vi.po: Update translation (2009t0f0u)
  l10n: Update Swedish translation (2009t0f0u)
  l10n: git.pot: v1.8.2 round 4 (1 changed)

Merge branch 'mp/complete-paths'

* mp/complete-paths:
  git-completion.zsh: define __gitcomp_file compatibility function

Merge branch 'maint'

* maint:
  gitweb/README: remove reference to git.kernel.org

Merge branch 'mh/maint-ceil-absolute' into maint

* mh/maint-ceil-absolute:
  Provide a mechanism to turn off symlink resolution in ceiling paths

gitweb/README: remove reference to git.kernel.org

git.kernel.org no longer uses gitweb but has switched to cgit.

Info about this can be found on: https://www.kernel.org/pelican.html
or simply by looking at http://git.kernel.org . This is change since
2013-03-01.

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

l10n: zh_CN.po: translate 1 new message

Translate 1 new message came from git.pot update in ed1ddaf
(l10n: git.pot: v1.8.2 round 4 (1 changed)).

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

l10n: de.po: translate 1 new message

Translate 1 new message came from git.pot update in
ed1ddaf (l10n: git.pot: v1.8.2 round 4 (1 changed)).

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

l10n: vi.po: Update translation (2009t0f0u)

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>

git-completion.zsh: define __gitcomp_file compatibility function

Commit fea16b47b60 (Fri Jan 11 19:48:43 2013, Manlio Perillo,
git-completion.bash: add support for path completion), introduced a new
__gitcomp_file function that uses the bash builtin "compgen". The
function was redefined for ZSH in the deprecated section of
git-completion.bash, but not in the new git-completion.zsh script.

As a result, users of git-completion.zsh trying to complete "git add
fo<tab>" get an error:

git add fo__gitcomp_file:8: command not found: compgen

This patch adds the redefinition and removes the error.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: Update Swedish translation (2009t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

l10n: git.pot: v1.8.2 round 4 (1 changed)

Generate po/git.pot from v1.8.2-rc2-4-g77995 for git v1.8.2
l10n round 4.

Signed-off-by: Jiang Xin <worldhello.net@gmail.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

Git 1.8.2-rc2

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

Sync with 1.8.1.5

Git 1.8.1.5

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

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>

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'

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

* maint:
  Update draft release notes to 1.8.1.5
  Documentation/submodule: Add --force to update synopsis

Update draft release notes to 1.8.1.5

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

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

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 'jn/less-reconfigure' into maint

* jn/less-reconfigure:
  Makefile: avoid infinite loop on configure.ac change

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

Documentation/submodule: Add --force to update synopsis

In commit 9db31bdf (submodule: Add --force option for git submodule
update, 2011-04-01) we added the option to the implementation's usage
synopsis but forgot to add it to the synopsis in the command
documentation.  Add the option to the synopsis in the same location it
is reported in usage and re-wrap the options to avoid long lines.

Signed-off-by: Brad King <brad.king@kitware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'for-junio' of git://github.com/kusma/git

* 'for-junio' of git://github.com/kusma/git:
  wincred: improve compatibility with windows versions
  wincred: accept CRLF on stdin to simplify console usage

Revert "compat: add strtok_r()"

This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.

commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
the only call-site for strtok_r. So let's get rid of the compat
implementation as well.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

wincred: improve compatibility with windows versions

On WinXP, the windows credential helper doesn't work at all (due to missing
Cred[Un]PackAuthenticationBuffer APIs). On Win7, the credential format used
by wincred is incompatible with native Windows tools (such as the control
panel applet or 'cmdkey.exe /generic'). These Windows tools only set the
TargetName, UserName and CredentialBlob members of the CREDENTIAL
structure (where CredentialBlob is the UTF-16-encoded password).

Remove the unnecessary packing / unpacking of the password, along with the
related API definitions, for compatibility with Windows XP.

Don't use CREDENTIAL_ATTRIBUTEs to identify credentials for compatibility
with Windows credential manager tools. Parse the protocol, username, host
and path fields from the credential's target name instead.

Credentials created with an old wincred version will have mangled or empty
passwords after this change.

Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>

wincred: accept CRLF on stdin to simplify console usage

The windows credential helper currently only accepts LF on stdin, but bash
and cmd.exe both send CRLF. This prevents interactive use in the console.

Change the stdin parser to optionally accept CRLF.

Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>

l10n: de.po: correct translation of "bisect" messages

The term "bisect" was translated as "halbieren", we should
translate it as "binäre Suche" (binary search). While at
there, we should leave "bisect run" untranslated since it's
a subcommand of "git bisect".

Suggested-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>

l10n: de.po: translate 5 new messages

Translate 5 new messages came from git.pot update in 235537a
(l10n: git.pot: v1.8.2 round 3 (5 new)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Thomas Rast <trast@inf.ethz.ch>

l10n: de.po: translate 35 new messages

Translate 35 new messages came from git.pot update
in 9caaf23 (l10n: Update git.pot (35 new, 14 removed
messages)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Thomas Rast <trast@inf.ethz.ch>

Git 1.8.2-rc1

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: vi.po: Updated 5 new messages (2009t0f0u)
  l10n: Update Swedish translation (2009t0f0u)
  l10n: Update Swedish translation (2004t0f0u)
  l10n: zh_CN.po: translate 5 new messages
  l10n: git.pot: v1.8.2 round 3 (5 new)

Sync with 'maint'

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

Merge branch 'wk/user-manual'

Further updates to the user manual.

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

Merge branch 'jn/less-reconfigure'

A change made on v1.8.1.x maintenance track had a nasty regression
to break the build when autoconf is used.

* jn/less-reconfigure:
  Makefile: avoid infinite loop on configure.ac change

Merge branch 'as/check-ignore'

"git check-ignore ." segfaulted, as a function it calls deep in its
callchain took a string in the <ptr, length> form but did not stop
when given an empty string.

* as/check-ignore:
  name-hash: allow hashing an empty string
  t0008: document test_expect_success_multi

Merge branch 'ct/autoconf-htmldir'

An earlier change to config.mak.autogen broke a build driven by the
./configure script when --htmldir is not specified on the command
line of ./configure.

* ct/autoconf-htmldir:
  Bugfix: undefined htmldir in config.mak.autogen

Merge branch 'wk/man-deny-current-branch-is-default-these-days'

* wk/man-deny-current-branch-is-default-these-days:
  user-manual: typofix (ofthe->of the)

Prepare for 1.8.1.5

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

Merge branch 'jc/mention-tracking-for-pull-default' into maint

* jc/mention-tracking-for-pull-default:
  doc: mention tracking for pull.default

Merge branch 'mm/config-intro-in-git-doc' into maint

* mm/config-intro-in-git-doc:
  git.txt: update description of the configuration mechanism

Merge branch 'da/p4merge-mktemp-fix' into maint

* da/p4merge-mktemp-fix:
  p4merge: fix printf usage

Merge branch 'bw/get-tz-offset-perl' into maint

* bw/get-tz-offset-perl:
  cvsimport: format commit timestamp ourselves without using strftime
  perl/Git.pm: fix get_tz_offset to properly handle DST boundary cases
  Move Git::SVN::get_tz to Git::get_tz_offset

Merge branch 'al/mergetool-printf-fix' into maint

* al/mergetool-printf-fix:
  difftool--helper: fix printf usage
  git-mergetool: print filename when it contains %

Merge branch 'jx/utf8-printf-width' into maint

* jx/utf8-printf-width:
  Add utf8_fprintf helper that returns correct number of columns

Merge branch 'mg/bisect-doc' into maint

* mg/bisect-doc:
  git-bisect.txt: clarify that reset quits bisect

Merge branch 'sp/smart-http-content-type-check' into maint

* sp/smart-http-content-type-check:
  http_request: reset "type" strbuf before adding
  t5551: fix expected error output
  Verify Content-Type from smart HTTP servers

Merge branch 'jc/combine-diff-many-parents' into maint

* jc/combine-diff-many-parents:
  t4038: add tests for "diff --cc --raw <trees>"
  combine-diff: lift 32-way limit of combined diff

Merge branch 'jk/apply-similaritly-parsing' into maint

* jk/apply-similaritly-parsing:
  builtin/apply: tighten (dis)similarity index parsing

Merge branch 'jk/remote-helpers-doc' into maint

* jk/remote-helpers-doc:
  Rename {git- => git}remote-helpers.txt

Merge branch 'ab/gitweb-use-same-scheme' into maint

* ab/gitweb-use-same-scheme:
  gitweb: refer to picon/gravatar images over the same scheme

Merge branch 'zk/clean-report-failure' into maint

* zk/clean-report-failure:
  git-clean: Display more accurate delete messages

Merge branch 'nd/clone-no-separate-git-dir-with-bare' into maint

* nd/clone-no-separate-git-dir-with-bare:
  clone: forbid --bare --separate-git-dir <dir>

Merge branch 'da/p4merge-mktemp' into maint

* da/p4merge-mktemp:
  mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder

Documentation: "advice" is uncountable

"Advice" is a mass noun, not a count noun; it's not ordinarily
pluralized.

Signed-off-by: Greg Price <price@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Provide a mechanism to turn off symlink resolution in ceiling paths

Commit 1b77d83cab 'setup_git_directory_gently_1(): resolve symlinks
in ceiling paths' changed the setup code to resolve symlinks in the
entries in GIT_CEILING_DIRECTORIES.  Because those entries are
compared textually to the symlink-resolved current directory, an
entry in GIT_CEILING_DIRECTORIES that contained a symlink would have
no effect.  It was known that this could cause performance problems
if the symlink resolution *itself* touched slow filesystems, but it
was thought that such use cases would be unlikely.  The intention of
the earlier change was to deal with a case when the user has this:

GIT_CEILING_DIRECTORIES=/home/gitster

but in reality, /home/gitster is a symbolic link to somewhere else,
e.g. /net/machine/home4/gitster. A textual comparison between the
specified value /home/gitster and the location getcwd(3) returns
would not help us, but readlink("/home/gitster") would still be
fast.

After this change was released, Anders Kaseorg <andersk@mit.edu>
reported:

> [...] my computer has been acting so slow when I’m not connected to
> the network.  I put various network filesystem paths in
> $GIT_CEILING_DIRECTORIES, such as
> /afs/athena.mit.edu/user/a/n/andersk (to avoid hitting its parents
> /afs/athena.mit.edu, /afs/athena.mit.edu/user/a, and
> /afs/athena.mit.edu/user/a/n which all live in different AFS
> volumes).  Now when I’m not connected to the network, every
> invocation of Git, including the __git_ps1 in my shell prompt, waits
> for AFS to timeout.

To allow users to work around this problem, give them a mechanism to
turn off symlink resolution in GIT_CEILING_DIRECTORIES entries.  All
the entries that follow an empty entry will not be checked for symbolic
links and used literally in comparison.  E.g. with these:

GIT_CEILING_DIRECTORIES=:/foo/bar:/xyzzy or
GIT_CEILING_DIRECTORIES=/foo/bar::/xyzzy

we will not readlink("/xyzzy") because it comes after an empty entry.

With the former (but not with the latter), "/foo/bar" comes after an
empty entry, and we will not readlink it, either.

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

Makefile: avoid infinite loop on configure.ac change

If you are using autoconf and change the configure.ac, the
Makefile will notice that config.status is older than
configure.ac, and will attempt to rebuild and re-run the
configure script to pick up your changes. The first step in
doing so is to run "make configure". Unfortunately, this
tries to include config.mak.autogen, which depends on
config.status, which depends on configure.ac; so we must
rebuild config.status. Which leads to us running "make
configure", and so on.

It's easy to demonstrate with:

  make configure
  ./configure
  touch configure.ac
  make

We can break this cycle by not re-invoking make to build
"configure", and instead just putting its rules inline into
our config.status rebuild procedure.  We can avoid a copy by
factoring the rules into a make variable.

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

Sync with v1.8.1.4

Git 1.8.1.4

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

Merge branch 'ob/imap-send-ssl-verify' into maint

* ob/imap-send-ssl-verify:
  imap-send: support subjectAltName as well
  imap-send: the subject of SSL certificate must match the host
  imap-send: move #ifdef around

imap-send: support subjectAltName as well

Check not only the common name of the certificate subject, but also
check the subject alternative DNS names as well, when verifying that
the certificate matches that of the host we are trying to talk to.

Signed-off-by: Oswald Buddenhagen <ossi@kde.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

imap-send: the subject of SSL certificate must match the host

We did not check a valid certificate's subject at all, and would
have happily talked with a wrong host after connecting to an
incorrect address and getting a valid certificate that does not
belong to the host we intended to talk to.

Signed-off-by: Oswald Buddenhagen <ossi@kde.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: vi.po: Updated 5 new messages (2009t0f0u)

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>

Bugfix: undefined htmldir in config.mak.autogen

Html documents will be installed to root dir (/) no matter what prefix
is set, if run these commands before `make` and `make install-html`:

    $ make configure
    $ ./configure --prefix=<PREFIX>

After the installation, all the html documents will copy to rootdir (/),
and:

    $ git --html-path
    <PREFIX>

    $ git help -w something
    fatal: '<PREFIX>': not a documentation directory.

This is because the variable "htmldir" points to a undefined variable
"$(docdir)" in file "config.mak.autogen", which is generated by running
`./configure`. By default $(docdir) generated by configure is supposed
be set this way:

        datarootdir='${prefix}/share'
        htmldir='${docdir}'
        docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'

but since fc1c5415d69d (Honor configure's htmldir switch, 2013-02-02),
we only set and export htmldir without doing so for PACKAGE_TARNAME
(which is set to 'git' by the configure script).

Add the required two variables "PACKAGE_TARNAME" and "docdir" to file
"config.mak.in" will work this issue around.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

name-hash: allow hashing an empty string

Usually we do not pass an empty string to the function hash_name()
because we almost always ask for hash values for a path that is a
candidate to be added to the index. However, check-ignore (and most
likely check-attr, but I didn't check) apparently has a callchain
to ask the hash value for an empty path when it was given a "." from
the top-level directory to ask "Is the path . excluded by default?"

Make sure that hash_name() does not overrun the end of the given
pathname even when it is empty.

Remove a sweep-the-issue-under-the-rug conditional in check-ignore
that avoided to pass an empty string to the callchain while at it.
It is a valid question to ask for check-ignore if the top-level is
set to be ignored by default, even though the answer is most likely
no, if only because there is currently no way to specify such an
entry in the .gitignore file. But it is an unusual thing to ask and
it is not worth optimizing for it by special casing at the top level
of the call chain.

Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual: Flesh out uncommitted changes and submodule updates

If you try and update a submodule with a dirty working directory, you
get an error message like:

  $ git submodule update
  error: Your local changes to the following files would be overwritten by checkout:
  ...
  Please, commit your changes or stash them before you can switch branches.
  Aborting
  ...

Mention this in the submodule notes.  The previous phrase was short
enough that I originally thought it might have been referring to the
reflog note (obviously, uncommitted changes will not show up in the
reflog either ;).

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual: Use request-pull to generate "please pull" text

Less work and more error checking (e.g. does a merge base exist?).
Add an explicit push before request-pull to satisfy request-pull,
which checks to make sure the references are publically available.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual: Reorganize the reroll sections, adding 'git rebase -i'

I think this interface is often more convenient than extended cherry
picking or using 'git format-patch'.  In fact, I removed the
cherry-pick section entirely.  The entry-level suggestions for
rerolling are now:

    1. git commit --amend
    2. git format-patch origin
       git reset --hard origin
       ...edit and reorder patches...
       git am *.patch
    3. git rebase -i origin

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

t0008: document test_expect_success_multi

test_expect_success_multi() helper function warrants some explanation,
since at first sight it may seem like generic test framework plumbing,
but is in fact specific to testing check-ignore, and allows more
thorough testing of the various output formats without significantly
increase the size of t0008.

Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

l10n: Update Swedish translation (2009t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

l10n: Update Swedish translation (2004t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>

l10n: zh_CN.po: translate 5 new messages

Translate 5 new messages came from git.pot update in 235537a
(l10n: git.pot: v1.8.2 round 3 (5 new)).

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

l10n: git.pot: v1.8.2 round 3 (5 new)

Generate po/git.pot from v1.8.2-rc0-16-g20a59 for git v1.8.2
l10n round 3.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

imap-send: move #ifdef around

Instead of adding an early return to the inside of the
ssl_socket_connect() function for NO_OPENSSL compilation, split it
into a separate stub function.

No functional change, but the next change to extend ssl_socket_connect()
will become easier to read this way.

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

Merge branch 'jc/mention-tracking-for-pull-default'

We stopped mentioning `tracking` is a deprecated but supported
synonym for `upstream` in pull.default even though we have no
intention of removing the support for it.

* jc/mention-tracking-for-pull-default:
  doc: mention tracking for pull.default

Merge branch 'mm/config-intro-in-git-doc'

* mm/config-intro-in-git-doc:
  git.txt: update description of the configuration mechanism

RelNotes 1.8.2: push-simple will not be in effect in this release

Also migration path for the default behaviour of "git add -u/-A" run
in a subdirectory is worth mentioning.

Both pointed out by Matthieu Moy.

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

shell-prompt: clean up nested if-then

Minor clean up of if-then nesting in checks for environment variables
and config options. No functional changes.

Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual: typofix (ofthe->of the)

Noticed by Drew Northup

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

Merge branch 'maint'

* maint:
  user-manual: use -o latest.tar.gz to create a gzipped tarball
  user-manual: use 'git config --global user.*' for setup
  user-manual: mention 'git remote add' for remote branch config
  user-manual: give 'git push -f' as an alternative to +master
  user-manual: use 'remote add' to setup push URLs

user-manual: use -o latest.tar.gz to create a gzipped tarball

This functionality was introduced by 0e804e09 (archive: provide
builtin .tar.gz filter, 2011-07-21) for v1.7.7.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual: use 'git config --global user.*' for setup

A simple command line call is easier than spawning an editor,
especially for folks new to ideas like the "command line" and "text
editors".  This is also the approach suggested by 'git commit' if you
try and commit without having configured user.name or user.email.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual: mention 'git remote add' for remote branch config

I hardly ever setup remote.<name>.url using 'git config'.  While it
may be instructive to do so, we should also point out 'git remote
add'.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual: give 'git push -f' as an alternative to +master

This mirrors existing language in the description of 'git fetch'.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

user-manual: use 'remote add' to setup push URLs

There is no need to use here documents to setup this configuration.
It is easier, less confusing, and more robust to use `git remote add`
directly.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>