* maint:
  rev-parse: clarify documentation of $name@{upstream} syntax
  sha1_name: pass object name length to diagnose_invalid_sha1_path()
  Makefile: keep LIB_H entries together and sorted

"git rev-parse" interprets string in string@{upstream} as a name of
a branch not a ref. For example, refs/heads/master@{upstream} looks
for an upstream branch that is merged by git-pull to ref
refs/heads/refs/heads/master not to refs/heads/master.

However the documentation could mislead a user to believe that the
string is interpreted as ref.
Signed-off-by: NKacper Kornet <draenog@pld-linux.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The only caller of diagnose_invalid_sha1_path() extracts a substring from
an object name by creating a NUL-terminated copy of the interesting part.
Add a length parameter to the function and thus avoid the need for an
allocation, thereby simplifying the code.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As a follow-up to 60d24dd2 (Makefile: fold XDIFF_H and VCSSVN_H into
LIB_H), let the unconditional additions to LIB_H form a single sorted
list.  Also drop the duplicate entry for xdiff/xdiff.h, which was easy
to spot after sorting.
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* maint:
  git.c: make usage match manual page

Reorder option list in command-line usage to match the manual page.
Also make it less than 80-characters wide.
Signed-off-by: NKevin Bracey <kevin@bracey.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* mp/complete-paths:
  git-completion.bash: zsh does not implement function redirection correctly

* mm/add-u-A-finishing-touches:
  add: update pathless 'add [-u|-A]' warning to reflect change of plan

A recent change added functions whose entire standard error stream
is redirected to /dev/null using a construct that is valid POSIX.1
but is not widely used:

	funcname () {
		cd "$1" && run some command "$2"
	} 2>/dev/null

Even though this file is "git-completion.bash", zsh completion
support dot-sources it (instead of asking bash to grok it like tcsh
completion does), and zsh does not implement this redirection
correctly.

With zsh, trying to complete an inexistant directory gave this:

  git add no-such-dir/__git_ls_files_helper:cd:2: no such file or directory: no-such-dir/

Also these functions use "cd" to first go somewhere else before
running a command, but the location the caller wants them to go that
is given as an argument to them should not be affected by CDPATH
variable the users may have set for their interactive session.

To fix both of these, wrap the body of the function in a subshell,
unset CDPATH at the beginning of the subshell, and redirect the
standard error stream of the subshell to /dev/null.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* gp/add-u-A-documentation:
  add: Clarify documentation of -A and -u

We originally thought the transition would need a period where "git add
[-u|-A]" without pathspec would be forbidden, but the warning is big
enough to scare people and teach them not to use it (or, if so, to
understand the consequences).
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  Translate git_more_info_string consistently

"git help" translated the "See 'git help <command>' for more
information..." message, but "git" didn't.
Signed-off-by: NKevin Bracey <kevin@bracey.fi>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint:
  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: NAntoine Pelisse <apelisse@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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: NJunio C Hamano <gitster@pobox.com>

All other instances of "W:"-prefixed warning messages have a space after
the "W:" to help with readability.
Signed-off-by: NEric Wong <normalperson@yhbt.net>

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: NJan Pesta <jan.pesta@certicon.cz>
Signed-off-by: NEric Wong <normalperson@yhbt.net>

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

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

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

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

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

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: NFredrik Gustafsson <iveqy@iveqy.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The documentation of '-A' and '-u' is very confusing for someone who
doesn't already know what they do.  Describe them with fewer words and
clearer parallelism to each other and to the behavior of plain 'add'.

Also mention the default <pathspec> for '-A' as well as '-u', because
it applies to both.
Signed-off-by: NGreg Price <price@mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Translate 1 new message came from git.pot update in ed1ddafa
(l10n: git.pot: v1.8.2 round 4 (1 changed)).
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>

Translate 1 new message came from git.pot update in
ed1ddafa (l10n: git.pot: v1.8.2 round 4 (1 changed)).
Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com>

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

Commit fea16b47 (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: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

Generate po/git.pot from v1.8.2-rc2-4-g77995 for git v1.8.2
l10n round 4.
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>

* 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

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

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

Before 82dce998 (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 82dce998
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 82dce998 '!' matched that literal
character, so it is conceivable that users have .gitattributes with
such lines in them.  After 82dce998 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: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

Signed-off-by: NAndrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>