Commit Graph

32976 Commits

Author SHA1 Message Date
Jeff King
cdf4fb8e33 pkt-line: drop safe_write function
This is just write_or_die by another name. The one
distinction is that write_or_die will treat EPIPE specially
by suppressing error messages. That's fine, as we die by
SIGPIPE anyway (and in the off chance that it is disabled,
write_or_die will simulate it).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 13:42:21 -08:00
Jeff King
e148542870 pkt-line: move a misplaced comment
The comment describing the packet writing interface was
originally written above packet_write, but migrated to be
above safe_write in f3a3214, probably because it is meant to
generally describe the packet writing interface and not a
single function. Let's move it into the header file, where
users of the interface are more likely to see it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 13:42:21 -08:00
Jeff King
756e676ca0 write_or_die: raise SIGPIPE when we get EPIPE
The write_or_die function will always die on an error,
including EPIPE. However, it currently treats EPIPE
specially by suppressing any error message, and by exiting
with exit code 0.

Suppressing the error message makes some sense; a pipe death
may just be a sign that the other side is not interested in
what we have to say. However, exiting with a successful
error code is not a good idea, as write_or_die is frequently
used in cases where we want to be careful about having
written all of the output, and we may need to signal to our
caller that we have done so (e.g., you would not want a push
whose other end has hung up to report success).

This distinction doesn't typically matter in git, because we
do not ignore SIGPIPE in the first place. Which means that
we will not get EPIPE, but instead will just die when we get
a SIGPIPE. But it's possible for a default handler to be set
by a parent process, or for us to add a callsite inside one
of our few SIGPIPE-ignoring blocks of code.

This patch converts write_or_die to actually raise SIGPIPE
when we see EPIPE, rather than exiting with zero. This
brings the behavior in line with the "normal" case that we
die from SIGPIPE (and any callers who want to check why we
died will see the same thing). We also give the same
treatment to other related functions, including
write_or_whine_pipe and maybe_flush_or_die.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 13:42:21 -08:00
Jeff King
090fd4fe24 upload-archive: use argv_array to store client arguments
The current parsing scheme for upload-archive is to pack
arguments into a fixed-size buffer, separated by NULs, and
put a pointer to each argument in the buffer into a
fixed-size argv array.

This works fine, and the limits are high enough that nobody
reasonable is going to hit them, but it makes the code hard
to follow.  Instead, let's just stuff the arguments into an
argv_array, which is much simpler. That lifts the "all
arguments must fit inside 4K together" limit.

We could also trivially lift the MAX_ARGS limitation (in
fact, we have to keep extra code to enforce it). But that
would mean a client could force us to allocate an arbitrary
amount of memory simply by sending us "argument" lines. By
limiting the MAX_ARGS, we limit an attacker to about 4
megabytes (64 times a maximum 64K packet buffer). That may
sound like a lot compared to the 4K limit, but it's not a
big deal compared to what git-archive will actually allocate
while working (e.g., to load blobs into memory). The
important thing is that it is bounded.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 13:42:21 -08:00
Jeff King
6379dd0522 upload-archive: do not copy repo name
According to the comment, enter_repo will modify its input.
However, this has not been the case since 1c64b48
(enter_repo: do not modify input, 2011-10-04). Drop the
now-useless copy.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 13:42:21 -08:00
Jeff King
8f9e3e498c send-pack: prefer prefixcmp over memcmp in receive_status
This code predates prefixcmp, so it used memcmp along with
static sizes. Replacing these memcmps with prefixcmp makes
the code much more readable, and the lack of static sizes
will make refactoring it in future patches simpler.

Note that we used to be unnecessarily liberal in parsing the
"unpack" status line, and would accept "unpack ok\njunk". No
version of git has ever produced that, and it violates the
BNF in Documentation/technical/pack-protocol.txt. Let's take
this opportunity to tighten the check by converting the
prefix comparison into a strcmp.

While we're in the area, let's also fix a vague error
message that does not follow our usual conventions (it
writes directly to stderr and does not use the "error:"
prefix).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 13:42:21 -08:00
Jeff King
030e9dd64f fetch-pack: fix out-of-bounds buffer offset in get_ack
When we read acks from the remote, we expect either:

  ACK <sha1>

or

  ACK <sha1> <multi-ack-flag>

We parse the "ACK <sha1>" bit from the line, and then start
looking for the flag strings at "line+45"; if we don't have
them, we assume it's of the first type.  But if we do have
the first type, then line+45 is not necessarily inside our
string at all!

It turns out that this works most of the time due to the way
we parse the packets. They should come in with a newline,
and packet_read puts an extra NUL into the buffer, so we end
up with:

  ACK <sha1>\n\0

with the newline at offset 44 and the NUL at offset 45. We
then strip the newline, putting a NUL at offset 44. So
when we look at "line+45", we are looking past the end of
our string; but it's OK, because we hit the terminator from
the original string.

This breaks down, however, if the other side does not
terminate their packets with a newline. In that case, our
packet is one character shorter, and we start looking
through uninitialized memory for the flag. No known
implementation sends such a packet, so it has never come up
in practice.

This patch tightens the check by looking for a short,
flagless ACK before trying to parse the flag.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 13:42:21 -08:00
Jeff King
97a83fa839 upload-pack: remove packet debugging harness
If you set the GIT_DEBUG_SEND_PACK environment variable,
upload-pack will dump lines it receives in the receive_needs
phase to a descriptor. This debugging harness is a strict
subset of what GIT_TRACE_PACKET can do. Let's just drop it
in favor of that.

A few tests used GIT_DEBUG_SEND_PACK to confirm which
objects get sent; we have to adapt them to the new output
format.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 13:42:21 -08:00
Jeff King
e58e57e49e upload-pack: do not add duplicate objects to shallow list
When the client tells us it has a shallow object via
"shallow <sha1>", we make sure we have the object, mark it
with a flag, then add it to a dynamic array of shallow
objects. This means that a client can get us to allocate
arbitrary amounts of memory just by flooding us with shallow
lines (whether they have the objects or not). You can
demonstrate it easily with:

  yes '0035shallow e83c5163316f89bfbde7d9ab23ca2e25604af290' |
  git-upload-pack git.git

We already protect against duplicates in want lines by
checking if our flag is already set; let's do the same thing
here. Note that a client can still get us to allocate some
amount of memory by marking every object in the repo as
"shallow" (or "want"). But this at least bounds it with the
number of objects in the repository, which is not under the
control of an upload-pack client.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 13:42:21 -08:00
Jeff King
b7b021701c upload-pack: use get_sha1_hex to parse "shallow" lines
When we receive a line like "shallow <sha1>" from the
client, we feed the <sha1> part to get_sha1. This is a
mistake, as the argument on a shallow line is defined by
Documentation/technical/pack-protocol.txt to contain an
"obj-id".  This is never defined in the BNF, but it is clear
from the text and from the other uses that it is meant to be
a hex sha1, not an arbitrary identifier (and that is what
fetch-pack has always sent).

We should be using get_sha1_hex instead, which doesn't allow
the client to request arbitrary junk like "HEAD@{yesterday}".
Because this is just marking shallow objects, the client
couldn't actually do anything interesting (like fetching
objects from unreachable reflog entries), but we should keep
our parsing tight to be on the safe side.

Because get_sha1 is for the most part a superset of
get_sha1_hex, in theory the only behavior change should be
disallowing non-hex object references. However, there is
one interesting exception: get_sha1 will only parse
a 40-character hex sha1 if the string has exactly 40
characters, whereas get_sha1_hex will just eat the first 40
characters, leaving the rest. That means that current
versions of git-upload-pack will not accept a "shallow"
packet that has a trailing newline, even though the protocol
documentation is clear that newlines are allowed (even
encouraged) in non-binary parts of the protocol.

This never mattered in practice, though, because fetch-pack,
contrary to the protocol documentation, does not include a
newline in its shallow lines. JGit follows its lead (though
it correctly is strict on the parsing end about wanting a
hex object id).

We do not adjust fetch-pack to send newlines here, as it
would break communication with older versions of git (and
there is no actual benefit to doing so, except for
consistency with other parts of the protocol).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-20 13:42:20 -08:00
David Aguilar
9e5a86f204 t7800: update copyright notice
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 22:58:26 -08:00
Junio C Hamano
b3600c3628 Sync with v1.8.1.4 2013-02-19 21:57:27 -08:00
Junio C Hamano
dff9f8835f Git 1.8.1.4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 21:54:22 -08:00
Junio C Hamano
0ee7198f45 Merge branch 'ob/imap-send-ssl-verify' into maint
* ob/imap-send-ssl-verify:
  imap-send: support subjectAltName as well
  imap-send: the subject of SSL certificate must match the host
  imap-send: move #ifdef around
2013-02-19 21:54:15 -08:00
Oswald Buddenhagen
e174744ad1 imap-send: support subjectAltName as well
Check not only the common name of the certificate subject, but also
check the subject alternative DNS names as well, when verifying that
the certificate matches that of the host we are trying to talk to.

Signed-off-by: Oswald Buddenhagen <ossi@kde.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 21:47:22 -08:00
Oswald Buddenhagen
b62fb077d5 imap-send: the subject of SSL certificate must match the host
We did not check a valid certificate's subject at all, and would
have happily talked with a wrong host after connecting to an
incorrect address and getting a valid certificate that does not
belong to the host we intended to talk to.

Signed-off-by: Oswald Buddenhagen <ossi@kde.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 21:47:22 -08:00
Tran Ngoc Quan
c527acebc2 l10n: vi.po: Updated 5 new messages (2009t0f0u)
Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
2013-02-20 07:17:58 +07:00
Jiang Xin
55d9bf0aa8 Bugfix: undefined htmldir in config.mak.autogen
Html documents will be installed to root dir (/) no matter what prefix
is set, if run these commands before `make` and `make install-html`:

    $ make configure
    $ ./configure --prefix=<PREFIX>

After the installation, all the html documents will copy to rootdir (/),
and:

    $ git --html-path
    <PREFIX>

    $ git help -w something
    fatal: '<PREFIX>': not a documentation directory.

This is because the variable "htmldir" points to a undefined variable
"$(docdir)" in file "config.mak.autogen", which is generated by running
`./configure`. By default $(docdir) generated by configure is supposed
be set this way:

        datarootdir='${prefix}/share'
        htmldir='${docdir}'
        docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'

but since fc1c5415d6 (Honor configure's htmldir switch, 2013-02-02),
we only set and export htmldir without doing so for PACKAGE_TARNAME
(which is set to 'git' by the configure script).

Add the required two variables "PACKAGE_TARNAME" and "docdir" to file
"config.mak.in" will work this issue around.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 15:27:08 -08:00
Junio C Hamano
c19387e799 name-hash: allow hashing an empty string
Usually we do not pass an empty string to the function hash_name()
because we almost always ask for hash values for a path that is a
candidate to be added to the index. However, check-ignore (and most
likely check-attr, but I didn't check) apparently has a callchain
to ask the hash value for an empty path when it was given a "." from
the top-level directory to ask "Is the path . excluded by default?"

Make sure that hash_name() does not overrun the end of the given
pathname even when it is empty.

Remove a sweep-the-issue-under-the-rug conditional in check-ignore
that avoided to pass an empty string to the callchain while at it.
It is a valid question to ask for check-ignore if the top-level is
set to be ignored by default, even though the answer is most likely
no, if only because there is currently no way to specify such an
entry in the .gitignore file. But it is an unusual thing to ask and
it is not worth optimizing for it by special casing at the top level
of the call chain.

Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 14:00:12 -08:00
W. Trevor King
9148673377 user-manual: Flesh out uncommitted changes and submodule updates
If you try and update a submodule with a dirty working directory, you
get an error message like:

  $ git submodule update
  error: Your local changes to the following files would be overwritten by checkout:
  ...
  Please, commit your changes or stash them before you can switch branches.
  Aborting
  ...

Mention this in the submodule notes.  The previous phrase was short
enough that I originally thought it might have been referring to the
reflog note (obviously, uncommitted changes will not show up in the
reflog either ;).

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 12:56:30 -08:00
W. Trevor King
ae6ef554c8 user-manual: Use request-pull to generate "please pull" text
Less work and more error checking (e.g. does a merge base exist?).
Add an explicit push before request-pull to satisfy request-pull,
which checks to make sure the references are publically available.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 12:56:30 -08:00
W. Trevor King
6c26bf4d4e user-manual: Reorganize the reroll sections, adding 'git rebase -i'
I think this interface is often more convenient than extended cherry
picking or using 'git format-patch'.  In fact, I removed the
cherry-pick section entirely.  The entry-level suggestions for
rerolling are now:

    1. git commit --amend
    2. git format-patch origin
       git reset --hard origin
       ...edit and reorder patches...
       git am *.patch
    3. git rebase -i origin

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 12:56:11 -08:00
Brandon Casey
46fbf75364 Documentation/git-commit.txt: rework the --cleanup section
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 12:36:06 -08:00
Adam Spiers
6866654627 t0008: document test_expect_success_multi
test_expect_success_multi() helper function warrants some explanation,
since at first sight it may seem like generic test framework plumbing,
but is in fact specific to testing check-ignore, and allows more
thorough testing of the various output formats without significantly
increase the size of t0008.

Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 09:37:39 -08:00
Brandon Casey
a24a41ea9a git-commit: only append a newline to -m mesg if necessary
Currently, git will append two newlines to every message supplied via
the -m switch.  The purpose of this is to allow -m to be supplied
multiple times and have each supplied string become a paragraph in the
resulting commit message.

Normally, this does not cause a problem since any trailing newlines will
be removed by the cleanup operation.  If cleanup=verbatim for example,
then the trailing newlines will not be removed and will survive into the
resulting commit message.

Instead, let's ensure that the string supplied to -m is newline terminated,
but only append a second newline when appending additional messages.

Fixes the test in t7502.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 09:30:50 -08:00
Brandon Casey
5b012c80a1 t7502: demonstrate breakage with a commit message with trailing newlines
This test attempts to verify that a commit message supplied to 'git
commit' via the -m switch was used in full as the commit message for a
commit when --cleanup=verbatim was used.

But, this test has been broken since it was introduced.  Since the
commit message containing trailing newlines was supplied to 'git commit'
using a command substitution, the trailing newlines were removed by the
shell.  This means that a string without any trailing newlines was
actually supplied to 'git commit'.

The test was able to complete successfully since internally, git appends
two newlines to each string supplied via the -m switch.  So, the two
newlines removed by the shell were then re-added by git, and the
resulting commit matched what was expected.

So, let's move the initial creation of the commit message string out
from within a previous test so that it stands alone.  Assign the desired
commit message to a variable using literal newlines.  Then populate the
expect file from the contents of the commit message variable.  This way
the shell variable becomes the authoritative source of the commit
message and can be supplied via the -m switch with the trailing newlines
intact.

Mark this test as failing, since it is not handled correctly by git.
As described above, git appends two extra newlines to every string
supplied via -m, even to the ones that already end with a newline.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 09:30:23 -08:00
Brandon Casey
67dabab058 t/t7502: compare entire commit message with what was expected
This test attempts to verify that a commit in "verbatim" mode, when
supplied a commit template, produces a commit in which the commit
message matches exactly the template that was supplied.  But, since the
commit operation appends additional instructions for the user as
comments in the commit buffer, which would cause the comparison to fail,
this test decided to compare only the first three lines (the length of
the template) of the resulting commit message to the original template
file.

This has two problems.

  1. It does not allow the template to be lengthened or shortened
     without also modifying the number of lines that are considered
     significant (i.e. the argument to 'head -n').
  2. It will not catch a bug in git that causes git to append additional
     lines to the commit message.

So, let's use the --no-status option to 'git commit' which will cause
git to refrain from appending the lines of instructional text to the
commit message.  This will allow the entire resulting commit message to
be compared against the expected value.

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-19 09:29:13 -08:00
Peter Krefting
2afd3ef728 l10n: Update Swedish translation (2009t0f0u)
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2013-02-19 10:26:36 +01:00
Peter Krefting
1415174ad5 l10n: Update Swedish translation (2004t0f0u)
Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
2013-02-19 10:23:54 +01:00
Jiang Xin
63af42fe30 l10n: zh_CN.po: translate 5 new messages
Translate 5 new messages came from git.pot update in 235537a
(l10n: git.pot: v1.8.2 round 3 (5 new)).

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2013-02-19 14:52:24 +08:00
Jiang Xin
235537a07e l10n: git.pot: v1.8.2 round 3 (5 new)
Generate po/git.pot from v1.8.2-rc0-16-g20a59 for git v1.8.2
l10n round 3.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2013-02-19 13:36:11 +08:00
Junio C Hamano
1e1fe52923 imap-send: move #ifdef around
Instead of adding an early return to the inside of the
ssl_socket_connect() function for NO_OPENSSL compilation, split it
into a separate stub function.

No functional change, but the next change to extend ssl_socket_connect()
will become easier to read this way.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-18 16:33:07 -08:00
Junio C Hamano
20a599e2c1 Merge branch 'jc/mention-tracking-for-pull-default'
We stopped mentioning `tracking` is a deprecated but supported
synonym for `upstream` in pull.default even though we have no
intention of removing the support for it.

* jc/mention-tracking-for-pull-default:
  doc: mention tracking for pull.default
2013-02-18 16:05:03 -08:00
Junio C Hamano
48050fbe15 Merge branch 'mm/config-intro-in-git-doc'
* mm/config-intro-in-git-doc:
  git.txt: update description of the configuration mechanism
2013-02-18 16:04:58 -08:00
Junio C Hamano
ce209d0c72 RelNotes 1.8.2: push-simple will not be in effect in this release
Also migration path for the default behaviour of "git add -u/-A" run
in a subdirectory is worth mentioning.

Both pointed out by Matthieu Moy.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-18 15:59:33 -08:00
Martin Erik Werner
31e6a4e613 shell-prompt: clean up nested if-then
Minor clean up of if-then nesting in checks for environment variables
and config options. No functional changes.

Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-18 15:33:31 -08:00
Junio C Hamano
50995edda6 user-manual: typofix (ofthe->of the)
Noticed by Drew Northup

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-18 12:43:00 -08:00
Junio C Hamano
4cb8a83bb8 Merge branch 'maint'
* maint:
  user-manual: use -o latest.tar.gz to create a gzipped tarball
  user-manual: use 'git config --global user.*' for setup
  user-manual: mention 'git remote add' for remote branch config
  user-manual: give 'git push -f' as an alternative to +master
  user-manual: use 'remote add' to setup push URLs
2013-02-18 00:50:33 -08:00
W. Trevor King
7ed1690c34 user-manual: use -o latest.tar.gz to create a gzipped tarball
This functionality was introduced by 0e804e09 (archive: provide
builtin .tar.gz filter, 2011-07-21) for v1.7.7.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-18 00:48:52 -08:00
W. Trevor King
632cc3e6b6 user-manual: use 'git config --global user.*' for setup
A simple command line call is easier than spawning an editor,
especially for folks new to ideas like the "command line" and "text
editors".  This is also the approach suggested by 'git commit' if you
try and commit without having configured user.name or user.email.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-18 00:48:47 -08:00
W. Trevor King
47adb8ac7c user-manual: mention 'git remote add' for remote branch config
I hardly ever setup remote.<name>.url using 'git config'.  While it
may be instructive to do so, we should also point out 'git remote
add'.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-18 00:48:42 -08:00
W. Trevor King
d1471e0616 user-manual: give 'git push -f' as an alternative to +master
This mirrors existing language in the description of 'git fetch'.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-18 00:48:37 -08:00
W. Trevor King
e9b4908302 user-manual: use 'remote add' to setup push URLs
There is no need to use here documents to setup this configuration.
It is easier, less confusing, and more robust to use `git remote add`
directly.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-18 00:48:30 -08:00
Junio C Hamano
461247b51d Merge git://github.com/git-l10n/git-po
* git://github.com/git-l10n/git-po:
  l10n: zh_CN.po: translate 35 new messages
  l10n: vi.po: update new strings (2004t0u0f)
  l10n: Update git.pot (35 new, 14 removed messages)
2013-02-18 00:01:12 -08:00
Jiang Xin
a77c07d974 l10n: zh_CN.po: translate 35 new messages
Translate 35 new messages came from git.pot update in 9caaf23
(l10n: Update git.pot (35 new, 14 removed messages)).

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
2013-02-18 09:52:33 +08:00
Junio C Hamano
004825d314 Git 1.8.2-rc0
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-17 15:35:33 -08:00
Junio C Hamano
ce735bf7fd Merge branch 'jc/hidden-refs'
Allow the server side to redact the refs/ namespace it shows to the
client.

Will merge to 'master'.

* jc/hidden-refs:
  upload/receive-pack: allow hiding ref hierarchies
  upload-pack: simplify request validation
  upload-pack: share more code
2013-02-17 15:25:57 -08:00
Junio C Hamano
abea4dc76a Merge branch 'mp/diff-algo-config'
Add diff.algorithm configuration so that the user does not type
"diff --histogram".

* mp/diff-algo-config:
  diff: Introduce --diff-algorithm command line option
  config: Introduce diff.algorithm variable
  git-completion.bash: Autocomplete --minimal and --histogram for git-diff
2013-02-17 15:25:52 -08:00
Junio C Hamano
adbbc6f291 Merge branch 'mw/bash-prompt-show-untracked-config'
Allows skipping the untracked check GIT_PS1_SHOWUNTRACKEDFILES
asks for the git-prompt (in contrib/) per repository.

* mw/bash-prompt-show-untracked-config:
  t9903: add extra tests for bash.showDirtyState
  t9903: add tests for bash.showUntrackedFiles
  shell prompt: add bash.showUntrackedFiles option
2013-02-17 15:25:46 -08:00
Junio C Hamano
00abd715ab Merge branch 'jk/rebase-i-comment-char'
Finishing touches to the earlier core.commentchar topic to cover
"rebase -i" as well.

* jk/rebase-i-comment-char:
  rebase -i: respect core.commentchar
2013-02-17 15:25:20 -08:00