l10n: Unify the translation for '(un)expected'

Signed-off-by: Thynson <lanxingcan@gmail.com>
l10n: Improve many translation for zh_CN

Signed-off-by: Thynson <lanxingcan@gmail.com>
archive-zip: support UTF-8 paths

Set general purpose flag 11 if we encounter a path that contains
non-ASCII characters.  We assume that all paths are given as UTF-8; no
conversion is done.

The flag seems to be ignored by unzip unless we also mark the archive
entry as coming from a Unix system.  This is done by setting the field
creator_version ("version made by" in the standard[1]) to 0x03NN.

The NN part represents the version of the standard supported by us, and
this patch sets it to 3f (for version 6.3) for Unix paths.  We keep
creator_version set to 0 (FAT filesystem, standard version 0) in the
non-special cases, as before.

But when we declare a file to have a Unix path, then we have to set the
file mode as well, or unzip will extract the files with the permission
set 0000, i.e. inaccessible by all.

[1] http://www.pkware.com/documents/casestudies/APPNOTE.TXT

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
l10n: Update git.pot (825 new, 24 removed messages)

Generate po/git.pot from v1.7.12-437-g1084f with these i18n update(s):

 * i18n: mark more index-pack strings for translation
 * i18n: write-tree: mark parseopt strings for translation
 * i18n: verify-tag: mark parseopt strings for translation
 * i18n: verify-pack: mark parseopt strings for translation
 * i18n: update-server-info: mark parseopt strings for translation
 * i18n: update-ref: mark parseopt strings for translation
 * i18n: update-index: mark parseopt strings for translation
 * i18n: tag: mark parseopt strings for translation
 * i18n: symbolic-ref: mark parseopt strings for translation
 * i18n: show-ref: mark parseopt strings for translation
 * i18n: show-branch: mark parseopt strings for translation
 * i18n: shortlog: mark parseopt strings for translation
 * i18n: rm: mark parseopt strings for translation
 * i18n: revert, cherry-pick: mark parseopt strings for translation
 * i18n: rev-parse: mark parseopt strings for translation
 * i18n: reset: mark parseopt strings for translation
 * i18n: rerere: mark parseopt strings for translation
 * i18n: status: mark parseopt strings for translation
 * i18n: replace: mark parseopt strings for translation
 * i18n: remote: mark parseopt strings for translation
 * i18n: read-tree: mark parseopt strings for translation
 * i18n: push: mark parseopt strings for translation
 * i18n: prune: mark parseopt strings for translation
 * i18n: prune-packed: mark parseopt strings for translation
 * i18n: pack-refs: mark parseopt strings for translation
 * i18n: pack-objects: mark parseopt strings for translation
 * i18n: notes: mark parseopt strings for translation
 * i18n: name-rev: mark parseopt strings for translation
 * i18n: mv: mark parseopt strings for translation
 * i18n: mktree: mark parseopt strings for translation
 * i18n: merge: mark parseopt strings for translation
 * i18n: merge-file: mark parseopt strings for translation
 * i18n: merge-base: mark parseopt strings for translation
 * i18n: ls-tree: mark parseopt strings for translation
 * i18n: ls-files: mark parseopt strings for translation
 * i18n: log: mark parseopt strings for translation
 * i18n: init-db: mark parseopt strings for translation
 * i18n: help: mark parseopt strings for translation
 * i18n: hash-object: mark parseopt strings for translation
 * i18n: grep: mark parseopt strings for translation
 * i18n: gc: mark parseopt strings for translation
 * i18n: fsck: mark parseopt strings for translation
 * i18n: format-patch: mark parseopt strings for translation
 * i18n: for-each-ref: mark parseopt strings for translation
 * i18n: fmt-merge-msg: mark parseopt strings for translation
 * i18n: fetch: mark parseopt strings for translation
 * i18n: fast-export: mark parseopt strings for translation
 * i18n: describe: mark parseopt strings for translation
 * i18n: config: mark parseopt strings for translation
 * i18n: count-objects: mark parseopt strings for translation
 * i18n: commit: mark parseopt strings for translation
 * i18n: column: mark parseopt strings for translation
 * i18n: clone: mark parseopt strings for translation
 * i18n: clean: mark parseopt strings for translation
 * i18n: cherry: mark parseopt strings for translation
 * i18n: checkout: mark parseopt strings for translation
 * i18n: checkout-index: mark parseopt strings for translation
 * i18n: check-attr: mark parseopt strings for translation
 * i18n: cat-file: mark parseopt strings for translation
 * i18n: branch: mark parseopt strings for translation
 * i18n: blame: mark parseopt strings for translation
 * i18n: add: mark parseopt strings for translation
 * i18n: bisect--helper: mark parseopt strings for translation
 * i18n: archive: mark parseopt strings for translation
 * i18n: mark "style" in OPT_COLUMN() for translation

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
l10n: zh.CN.po: msgmerge git.pot (1142t195f630u)

Update of zh_CN.po: 1142 translated, 195 fuzzy, and 630 untranslated
messages.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
rebase usage: subcommands can not be combined with -i

Since 95135b0 (rebase: stricter check of standalone sub command,
2011-02-06), git-rebase has not allowed to use -i together with e.g.
--continue. Yet, when rebase started using OPTIONS_SPEC in 45e2acf
(rebase: define options in OPTIONS_SPEC, 2011-02-28), the usage message
included

	git-rebase [-i] --continue | --abort | --skip

Remove the "[-i]" from this line.

Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase -i: Refactor help messages for todo file

Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase -i: Teach "--edit-todo" action

This allows users to edit the todo file while they're stopped in the
middle of an interactive rebase. When this action is executed, all
comments from the original todo file are stripped, and new help messages
are appended to the end.

Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase -i: Add tests for "--edit-todo"

Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase -i: fix misleading error message after 'exec no-such' instruction

When the todo sheet of interactive rebase instructs to run a non-existing
command, the operation stops with the following error:

  Execution failed: no-such
  You can fix the problem, and then run

          git rebase --continue

  fatal: 'rebase' appears to be a git command, but we were not
  able to execute it. Maybe git-rebase is broken?

The reason is that the shell that attempted to run the command exits with
code 127. rebase--interactive just forwards this code to the caller (the
git wrapper). But our smart run-command infrastructure detects this
special exit code and turns it into ENOENT, which in turn is interpreted
by the git wrapper as if the external command that it just executed did
not exist. This is finally translated to the misleading last two lines in
error message cited above.

Fix it by translating the error code before it is forwarded.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revert "archive-zip: support UTF-8 paths"

This reverts commit 2162bd8cc461d6c3a12ab81c5db5a44bf5ecabc3; a
two-patch series to replace it will follow.
archive-zip: support UTF-8 paths

Set general purpose flag 11 if we encounter a path that contains
non-ASCII characters.  We assume that all paths are given as UTF-8; no
conversion is done.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase -i: suggest using --edit-todo to fix an unknown instruction

We have now an explicit UI to edit the todo sheet and need not disclose
the name of the file.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revert "retry request without query when info/refs?query fails"

This reverts commit 703e6e76a14825e5b0c960d525f34e607154b4f7.

Retrying without the query parameter was added as a workaround
for a single broken HTTP server at git.debian.org[1]. The server
was misconfigured to route every request with a query parameter
into gitweb.cgi. Admins fixed the server's configuration within
16 hours of the bug report to the Git mailing list, but we still
patched Git with this fallback and have been paying for it since.

Most Git hosting services configure the smart HTTP protocol and the
retry logic confuses users when there is a transient HTTP error as
Git dropped the real error from the smart HTTP request. Removing the
retry makes root causes easier to identify.

[1] http://thread.gmane.org/gmane.comp.version-control.git/137609

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Enable info/refs gzip decompression in HTTP client

Some HTTP servers try to use gzip compression on the /info/refs
request to save transfer bandwidth. Repositories with many tags
may find the /info/refs request can be gzipped to be 50% of the
original size due to the few but often repeated bytes used (hex
SHA-1 and commonly digits in tag names).

For most HTTP requests enable "Accept-Encoding: gzip" ensuring
the /info/refs payload can use this encoding format.

Only request gzip encoding from servers. Although deflate is
supported by libcurl, most servers have standardized on gzip
encoding for compression as that is what most browsers support.
Asking for deflate increases request sizes by a few bytes, but is
unlikely to ever be used by a server.

Disable the Accept-Encoding header on probe RPCs as response bodies
are supposed to be exactly 4 bytes long, "0000". The HTTP headers
requesting and indicating compression use more space than the data
transferred in the body.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-curl: rename is_http variable

We don't actually care whether the connection is http or
not; what we care about is whether it might be smart http.
Rename the variable to be more accurate, which will make it
easier to later make smart-http optional.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
clone --single: limit the fetch refspec to fetched branch

After running "git clone --single", the resulting repository has the
usual default "+refs/heads/*:refs/remotes/origin/*" wildcard fetch
refspec installed, which means that a subsequent "git fetch" will
end up grabbing all the other branches.

Update the fetch refspec to cover only the singly cloned ref instead
to correct this.

That means:
If "--single" is used without "--branch" or "--mirror", the
fetch refspec covers the branch on which remote's HEAD points to.
If "--single" is used with "--branch", it'll cover only the branch
specified in the "--branch" option.
If "--single" is combined with "--mirror", then it'll cover all
refs of the cloned repository.
If "--single" is used with "--branch" that specifies a tag, then
it'll cover only the ref for this tag.

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update Swedish translation (1967t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
receive-pack: redirect unpack-objects stdout to /dev/null

The unpack-objects command should not generally produce any
output on stdout. However, if it's given extra input after
the packfile, it will spew the remainder to stdout. When
called by receive-pack, this means we will break protocol,
since our stdout is connected to the remote send-pack.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
receive-pack: send pack-processing stderr over sideband

Receive-pack invokes either unpack-objects or index-pack to
handle the incoming pack. However, we do not redirect the
stderr of the sub-processes at all, so it is never seen by
the client. From the initial thread adding sideband support,
which is here:

  http://thread.gmane.org/gmane.comp.version-control.git/139471

it is clear that some messages are specifically kept off the
sideband (with the assumption that they are of interest only
to an administrator, not the client). The stderr of the
subprocesses is mentioned in the thread, but it's unclear if
they are included in that group, or were simply forgotten.

However, there are a few good reasons to show them to the
client:

  1. In many cases, they are directly about the incoming
     packfile (e.g., fsck warnings with --strict, corruption
     in the packfile, etc). Without these messages, the
     client just gets "unpacker error" with no extra useful
     diagnosis.

  2. No matter what the cause, we are probably better off
     showing the errors to the client. If the client and the
     server admin are not the same entity, it is probably
     much easier for the client to cut-and-paste the errors
     they see than for the admin to try to dig them out of a
     log and correlate them with a particular session.

  3. Users of the ssh transport typically already see these
     stderr messages, as the remote's stderr is copied
     literally by ssh. This brings other transports (http,
     and push-over-git if you are crazy enough to enable it)
     more in line with ssh. As a bonus for ssh users,
     because the messages are now fed through the sideband
     and printed by the local git, they will have "remote:"
     prepended and be properly interleaved with any local
     output to stderr.

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