* commit 'v1.6.4.4-8-g8de65185':
  Fix mis-backport of t7002

The original patch that became cfe370c6 (grep: do not segfault when -f is
used, 2009-10-16), was made against "maint" or newer branch back then, but
the fix addressed the issue that was present as far as in 1.6.4 series.

The maintainer backported the patch to the 1.6.4 maintenance branch, but
failed to notice that the new tests assumed the setup done by the script
in "maint", which did quite a lot more than the same test script in 1.6.4
series, and the output didn't match the expected result.

This should fix it.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently, when there is an invalid command, the rest of the line is
still treated as if the command had been valid, i.e. rebase -i attempts
to produce a patch, using the next argument as a SHA1 name. If there is
no next argument or an invalid one, very confusing error messages
appear (the line was '.'; path to git-rebase-todo substituted):

Unknown command: .
fatal: ambiguous argument 'Please fix this in the file $somefile.':
unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
fatal: Not a valid object name Please fix this in the file $somefile.
fatal: bad revision 'Please fix this in the file $somefile.'

Instead, verify the validity of the remaining line and error out earlier
if necessary.
Signed-off-by: NJan Krüger <jk@jk.gs>
Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

With this commit, git help -i <cmd> prints an error message and exits
non-zero instead of being silent and exit code 0.

Reported by Trent W. Buck through
 http://bugs.debian.org/537664Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jk/maint-1.6.3-ls-files-no-ignore-cached:
  ls-files: excludes should not impact tracked files

* jn/maint-1.6.3-check-ref-format-doc:
  Documentation: describe check-ref-format --branch

"git grep" would segfault if its -f option was used because it would
try to use an uninitialized strbuf, so initialize the strbuf.

Thanks to Johannes Sixt <j.sixt@viscovery.net> for the help with the
test cases.
Signed-off-by: NMatt Kraai <kraai@ftbfs.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Unless one already knew, it was not obvious what sort of shorthand
"git check-ref-format --branch" expands.  Explain it.

The --branch argument is not optional.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In all parts of git, .gitignore and other exclude files
impact only how we treat untracked files; they should have
no effect on files listed in the index.

This behavior was originally implemented very early on in
9ff768e9, but only for --exclude-from. Later, commit 63d285c8
accidentally caused us to trigger the behavior for
--exclude-per-directory.

This patch totally ignores excludes for files found in the
index. This means we are reversing the original intent of
9ff768e9, while at the same time fixing the accidental
behavior of 63d285c8. This is a good thing, though, as the
way that 9ff768e9 behaved does not really make sense with the
way exclusions are used in modern git.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When ls-files was called with -i but no exclude pattern, it was
calling fprintf(stderr, "...", NULL) and then exiting.  On Solaris,
passing NULL into fprintf was causing a segfault.  On glibc systems,
it was simply producing incorrect output (eg: "(null)": ...).  The
NULL pointer was a result of argv[0] not being preserved by the option
parser.  Instead of requesting that the option parser preserve
argv[0], use die() with a constant string.

A trigger for this bug was: `git ls-files -i`
Signed-off-by: NBen Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When reading the "raw format" timestamp from the input stream, make sure
that the timezone offset is a reasonable value by imitating 7122f82f
(date.c: improve guess between timezone offset and year., 2006-06-08).

We _might_ want to also check if the timestamp itself is reasonable, but
that is left for a separate commit.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* jc/maint-1.6.4-show-branch-default:
  show-branch: fix segfault when showbranch.default exists

When running "git show-branch" without any parameter in a repository that
has showbranch.default defined, we used to rely on the fact that our
handcrafted option parsing loop never looked at av[0].

The array of default strings had the first real command line argument in
default_arg[0], but the option parser wanted to look at the array starting
at av[1], so we assigned the address of -1th element to av to force the
loop start working from default_arg[0].

This no longer worked since 57343652 (show-branch: migrate to parse-options
API, 2009-05-21), as parse_options_start() saved the incoming &av[0] in
its ctx->out and later in parse_options_end() it did memmove to ctx->out
(with ctx->cpidx == 0), overwriting the memory before default_arg[] array.

I am not sure if this is a bug in parse_options(), or a bug in the caller,
and tonight I do not have enough concentration to figure out which.  In
any case, this patch works the issue around.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The variable is assigned unconditionally in print_push_status, but
print_push_status is not reached by all codepaths. In particular, this
fixes a bug where "git push ... nonexisting-branch" was complaining about
non-fast forward.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

* jc/maint-unpack-objects-strict:
  Fix "unpack-objects --strict"

Conflicts:
	builtin-unpack-objects.c

* tf/diff-whitespace-incomplete-line:
  xutils: Fix xdl_recmatch() on incomplete lines
  xutils: Fix hashing an incomplete line with whitespaces at the end

* jk/maint-1.6.3-checkout-unborn:
  checkout: do not imply "-f" on unborn branches

* jc/maint-checkout-index-to-prefix:
  check_path(): allow symlinked directories to checkout-index --prefix

* rc/maint-http-no-head-pack-check:
  http.c: avoid freeing an uninitialized pointer

An earlier 59b8d38f (http.c: remove verification of remote packs) left
the variable "url" uninitialized; "goto cleanup" codepath can free it
which is not very nice.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

Previously, the call to authors-prog was not properly escaped, so any
special characters in the Subversion username, such as spaces and
semi-colons, would be interpreted by the shell rather than being passed
in as the first argument.  Now all unsafe characters are escaped using
"git rev-parse --sq-quote"

[ew: switched from "\Q..\E" to "rev-parse --sq-quote"]
Signed-off-by: NMark Lodato <lodatom@gmail.com>
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* cb/maint-1.6.3-grep-relative-up:
  grep: accept relative paths outside current working directory
  grep: fix exit status if external_grep() punts

Conflicts:
	t/t7002-grep.sh

Make http.c::fetch_pack_index() no longer check for the remote pack
with a HEAD request before fetching the corresponding pack index file.

Not only does sending a HEAD request before we do a GET incur a
performance penalty, it does not offer any significant error-
prevention advantages (pack fetching in the *_http_pack_request()
methods is capable of handling any errors on its own).

This addresses an issue raised elsewhere:

  http://code.google.com/p/msysgit/issues/detail?id=323
  http://support.github.com/discussions/repos/957-cant-clone-over-http-or-gitSigned-off-by: NTay Ray Chuan <rctay89@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-pull.txt includes fetch-options.txt and merge-options.txt, both of
which document the --quiet and --verbose.

Supress the ones from fetch-options.txt.
Signed-off-by: NEmmanuel Trillaud <etrillaud@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

All hooks are currently in its own section. Which may confuse users,
because the section name serves as the hook file name and sections are
all caps for man pages. Putting them into a new HOOKS section and each
hook into a subsection keeps the case to lower case.
Signed-off-by: NBert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

"git grep" would barf at relative paths pointing outside the current
working directory (or subdirectories thereof). Use quote_path_relative(),
which can handle such cases just fine.

[jc: added tests.]
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If external_grep() is called and punts, grep_cache() mistakenly reported a
hit, even if there were none.  The bug can be triggered by calling "git
grep --no-color" from a subdirectory.
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The extreme raggedness of the right edge make this jarring
to read. Let's re-flow the text to fill the lines in a more
even way.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We must use an article when referring to the section
because it is a non-proper noun, and it must be the definite
article because we are referring to a specific section.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* maint-1.6.3:
  git-clone: add missing comma in --reference documentation
  git-cvsserver: no longer use deprecated 'git-subcommand' commands
  clone: disconnect transport after fetching

* maint-1.6.2:
  git-clone: add missing comma in --reference documentation
  clone: disconnect transport after fetching

Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-cvsserver still references git commands like 'git-config', which
is depcrecated.  This commit changes git-cvsserver to use the
'git subcommand' form.

Sylvain Beucler reported the problem through
 http://bugs.debian.org/536067Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The current code just leaves the transport in whatever state
it was in after performing the fetch.  For a non-empty clone
over the git protocol, the transport code already
disconnects at the end of the fetch.

But for an empty clone, we leave the connection hanging, and
eventually close the socket when clone exits. This causes
the remote upload-pack to complain "the remote end hung up
unexpectedly". While this message is harmless to the clone
itself, it is unnecessarily scary for a user to see and may
pollute git-daemon logs.

This patch just explicitly calls disconnect after we are
done with the remote end, which sends a flush packet to
upload-pack and cleanly disconnects, avoiding the error
message.

Other transports are unaffected or slightly improved:

 - for a non-empty repo over the git protocol, the second
   disconnect is a no-op (since we are no longer connected)

 - for "walker" transports (like HTTP or FTP), we actually
   free some used memory (which previously just sat until
   the clone process exits)

 - for "rsync", disconnect is always a no-op anyway
Signed-off-by: NJeff King <peff@peff.net>
Acked-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

This file is no longer used since 54bc13ce (t8005: Nobody writes Russian in
shift_jis, 2009-06-18).
Signed-off-by: NNanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* rc/maint-http-fix:
  http.c: don't assume that urls don't end with slash