add: Clarify documentation of -A and -u

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: Greg Price <price@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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 branch 'maint'

* maint:
  perf: update documentation of GIT_PERF_REPEAT_COUNT
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: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'

* maint:
  Translate git_more_info_string consistently
add: update pathless 'add [-u|-A]' warning to reflect change of plan

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: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'gp/add-u-A-documentation'

* gp/add-u-A-documentation:
  add: Clarify documentation of -A and -u
git-completion.bash: zsh does not implement function redirection correctly

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: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'mm/add-u-A-finishing-touches'

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

* mp/complete-paths:
  git-completion.bash: zsh does not implement function redirection correctly
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: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'

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

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: keep LIB_H entries together and sorted

As a follow-up to 60d24dd25 (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: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sha1_name: pass object name length to diagnose_invalid_sha1_path()

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: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rev-parse: clarify documentation of $name@{upstream} syntax

"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: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'

* 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
t1507: Test that branchname@{upstream} is interpreted as branch

Syntax branchname@{upstream} should interpret its argument as a name of
a branch. Add the test to check that it doesn't try to interpret it as a
refname if the branch in question does not exist.

Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint'

* maint:
  t1507: Test that branchname@{upstream} is interpreted as branch