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

* jn/maint-fast-import-empty-ls:
  fast-import: don't allow 'ls' of path with empty components
  fast-import: leakfix for 'ls' of dirty trees

* ph/rerere-doc:
  rerere: Document 'rerere remaining'

* ms/maint-config-error-at-eol-linecount:
  config: report errors at the EOL with correct line number

All of the other options were included in the synopsis, so it makes
sense to include these as well.
Signed-off-by: NMark Lodato <lodatom@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Previously GIT_EDITOR was not listed in git(1) "Environment Variables" section,
which could be very confusing to users. Include it in "other" subsection along
with a link to git-var(1), since that is the page that fully describes all
places where editor can be set and also their preference order.

Also, git-var(1) did not say that hardcoded fallback 'vi' may have been changed
at build time. A user could be puzzled if 'nano' pops up even when none of the
mentioned environment vars or config.editor are set. Clarify this.

Ideally, the build system should be changed to reflect the chosen fallback
editor when creating the man pages. Not sure if that is even possible though.
Signed-off-by: NRodrigo Silva (MestreLion) <linux@rodrigosilva.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

An alphabetic ordered list (a.) is converted to numerical in
the man page (1.) so context comments naming 'a' were confusing,
fix that by not using ordered list notation for 'a' anb 'b' items.
Signed-off-by: NNelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint-1.7.8:
  t/Makefile: Use $(sort ...) explicitly where needed
  gitweb: Fix actionless dispatch for non-existent objects
  i18n of multi-line advice messages

* ks/sort-wildcard-in-makefile:
  t/Makefile: Use $(sort ...) explicitly where needed

* jc/advise-i18n:
  i18n of multi-line advice messages

* jn/gitweb-unspecified-action:
  gitweb: Fix actionless dispatch for non-existent objects

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

"git bundle" did not record boundary commits correctly when there
are many of them.

By Thomas Rast
* tr/maint-bundle-boundary:
  bundle: keep around names passed to add_pending_object()
  t5510: ensure we stay in the toplevel test dir
  t5510: refactor bundle->pack conversion

"git diff-index" and its friends at the plumbing level showed the
"diff --git" header and nothing else for a path whose cached stat
info is dirty without actual difference when asked to produce a
patch. This was a longstanding bug that we could have fixed long
time ago.

By Junio C Hamano
* jc/maint-diff-patch-header:
  diff -p: squelch "diff --git" header for stat-dirty paths
  t4011: illustrate "diff-index -p" on stat-dirty paths
  t4011: modernise style

"gitweb" did use quotemeta() to prepare search string when asked to
do a fixed-string project search, but did not use it by mistake and
used the user-supplied string instead.

By Jakub Narebski
* jn/maint-do-not-match-with-unsanitized-searchtext:
  gitweb: Fix fixed string (non-regexp) project search

The code to synthesize the fake ancestor tree used by 3-way merge
fallback in "git am" was not prepared to read a patch created with
a non-standard -p<num> value.

* jc/am-3-nonstandard-popt:
  test: "am -3" can accept non-standard -p<num>
  am -3: allow nonstandard -p<num> option

A section in a config file with a missing "]" reports the next line
as bad, same goes to a value with a missing end quote.

This happens because the error is not detected until the end of the
line, when line number is already increased. Fix this by decreasing
line number by one for these cases.
Signed-off-by: NMartin Stenberg <martin@gnutiken.se>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As the fast-import manual explains:

	The value of <path> must be in canonical form. That is it must
	not:
	. contain an empty directory component (e.g. foo//bar is invalid),
	. end with a directory separator (e.g. foo/ is invalid),
	. start with a directory separator (e.g. /foo is invalid),

Unfortunately the "ls" command accepts these invalid syntaxes and
responds by declaring that the indicated path is missing.  This is too
subtle and causes importers to silently misbehave; better to error out
so the operator knows what's happening.

The C, R, and M commands already error out for such paths.
Reported-by: NAndrew Sayers <andrew-git@pileofstuff.org>
Analysis-by: NDavid Barr <davidbarr@google.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>

When the chosen directory has changed since it was last written to
pack, "tree_content_get" makes a deep copy of its content to scribble
on while computing the tree name, which we forgot to free.

This leak has been present since the 'ls' command was introduced in
v1.7.5-rc0~3^2~33 (fast-import: add 'ls' command, 2010-12-02).
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>

This adds the 'remaining' command to the documentation of
'git rerere'. This command was added in ac49f5ca (Feb 16 2011;
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>) but
it was never documented.

Touch up the other rerere commands to reduce noise.

First noticed by Vincent van Ravesteijn.
Signed-off-by: NPhil Hord <phil.hord@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Use $search_regexp, where regex metacharacters are quoted, for
searching projects list, rather than $searchtext, which contains
original search term.
Reported-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

OS X's sed and grep would complain with (respectively)

  sed: 1: "/^-/{p;q}": extra characters at the end of q command
  grep: Regular expression too big

For sed, use an explicit ; to terminate the q command.

For grep, spell the "40 hex digits" explicitly in the regex, which
should be safe as other tests already use this and we haven't got
breakage reports on OS X about them.
Signed-off-by: NThomas Rast <trast@inf.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

By Thomas Rast
* maint-1.7.8:
  Document the --histogram diff option

By Thomas Rast
* maint-1.7.7:
  Document the --histogram diff option

Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* jc/doc-merge-options:
  Documentation/merge-options.txt: group "ff" related options together

* cn/maint-rev-list-doc:
  Documentation: use {asterisk} in rev-list-options.txt when needed

When running t9300, valgrind (correctly) complains about an
uninitialized value in write_crash_report:

  ==2971== Use of uninitialised value of size 8
  ==2971==    at 0x4164F4: sha1_to_hex (hex.c:70)
  ==2971==    by 0x4073E4: die_nicely (fast-import.c:468)
  ==2971==    by 0x43284C: die (usage.c:86)
  ==2971==    by 0x40420D: main (fast-import.c:2731)
  ==2971==  Uninitialised value was created by a heap allocation
  ==2971==    at 0x4C29B3D: malloc (vg_replace_malloc.c:263)
  ==2971==    by 0x433645: xmalloc (wrapper.c:35)
  ==2971==    by 0x405DF5: pool_alloc (fast-import.c:619)
  ==2971==    by 0x407755: pool_calloc.constprop.14 (fast-import.c:634)
  ==2971==    by 0x403F33: main (fast-import.c:3324)

Fix this by zeroing all of the 'struct tag'.  We would only need to
zero out the 'sha1' field, but this way seems more future-proof.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* cn/maint-branch-with-bad:
  branch: don't assume the merge filter ref exists

Conflicts:
	t/t3200-branch.sh

* jn/maint-gitweb-invalid-regexp:
  gitweb: Handle invalid regexp in regexp search

* nd/maint-verify-objects:
  rev-list: fix --verify-objects --quiet becoming --objects
  rev-list: remove BISECT_SHOW_TRIED flag

* jk/maint-avoid-streaming-filtered-contents:
  do not stream large files to pack when filters are in use
  teach dry-run convert_to_git not to require a src buffer
  teach convert_to_git a "dry run" mode

* jb/filter-ignore-sigpipe:
  Ignore SIGPIPE when running a filter driver

* sp/smart-http-failure-to-push:
  : Mask SIGPIPE on the command channel going to a transport helper
  disconnect from remote helpers more gently

Conflicts:
	transport-helper.c

* tr/maint-bundle-long-subject:
  t5704: match tests to modern style
  strbuf: improve strbuf_get*line documentation
  bundle: use a strbuf to scan the log for boundary commits
  bundle: put strbuf_readline_fd in strbuf.c with adjustments

The current wording of the http.proxy documentation suggests that
http_proxy is somehow equivalent to http.proxy. However, while
http.proxy (by the means of curl's CURLOPT_PROXY option) overrides the
proxy for both HTTP and HTTPS protocols, the http_proxy environment
variable is used only for HTTP. But since the docs mention only
http_proxy, a user might expect it to apply to all HTTP-like protocols.

Avoid any such misunderstanding by explicitly mentioning https_proxy and
all_proxy as well.

Also replace linkgit:curl[1] with a literal 'curl(1)', because the
former gets translated to a dead link in the HTML pages.
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The construct 'while IFS== read' makes dash 0.5.6 execute
read without changing IFS, which results in test breakages
all over the place in t0300.  Neither dash 0.5.5.1 and older
nor dash 0.5.7 and newer are affected: The problem was
introduded resp. fixed by the commits

  55c46b7 ([BUILTIN] Honor tab as IFS whitespace when
           splitting fields in readcmd, 2009-08-11)

  1d806ac ([VAR] Do not poplocalvars prematurely on regular
           utilities, 2010-05-27)

in http://git.kernel.org/?p=utils/dash/dash.git

Putting 'IFS==' before that line makes all versions of dash
work.

This looks like a dash bug, not a misinterpretation of the
standard. However, it's worth working around for two
reasons. One, this version of dash was released in Fedora
14-16, so the bug is found in the wild. And two, at least
one other shell, Solaris /bin/sh, choked on this by
persisting IFS after the read invocation. That is not a
shell we usually care about, and I think this use of IFS is
acceptable by POSIX (which allows other behavior near
"special builtins", but "read" is not one of those). But it
seems that this may be a subtle, not-well-tested case for
some shells. Given that the workaround is so simple, it's
worth just being defensive.
Signed-off-by: NMichael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Prepare expected output inside test_expect_success that uses it.
Also remove excess blank lines.
Signed-off-by: NTom Grennan <tmgrennan@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>