gpg-interface: check good signature in a reliable way

Currently, verify_signed_buffer() only checks the return code of gpg,
and some callers implement additional unreliable checks for "Good
signature" in the gpg output meant for the user.

Use the status output instead and parse for a line beinning with
"[GNUPG:] GOODSIG ". This is the only reliable way of checking for a
good gpg signature.

If needed we can change this easily to "[GNUPG:] VALIDSIG " if we want
to take into account the trust model.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log-tree: rely upon the check in the gpg_interface

It's just so much clearer.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gpg_interface: allow to request status return

Currently, verify_signed_buffer() returns the user facing output only.

Allow callers to request the status output also.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty: parse the gpg status lines rather than the output

Currently, parse_signature_lines() parses the gpg output for strings
which depend on LANG so it fails to recognize good commit signatures
(and thus does not fill in %G? and the like) in most locales.

Make it parse the status lines from gpg instead, which are the proper
machine interface. This fixes the problem described above.

There is a change in behavior for "%GS" which we intentionally do not
work around: "%GS" used to put quotes around the signer's uid (or
rather: it inherited from the gpg user output). We output the uid
without quotes now, just like author and committer names.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty: make %GK output the signing key for signed commits

In order to employ signed keys in an automated way it is absolutely
necessary to check which keys the signatures come from.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
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>
imap-send: support Server Name Indication (RFC4366)

To talk with some sites that serve multiple names on a single IP
address, the client needs to ask for the specific host that it wants
to talk to.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
index-format.txt: mention of v4 is missing in some places

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
read-cache.c: use INDEX_FORMAT_{LB,UB} in verify_hdr()

9d22778 (read-cache.c: write prefix-compressed names in the index -
2012-04-04) defined these. Interestingly, they were not used by
read-cache.c, or anywhere in that patch. They were used in
builtin/update-index.c later for checking supported index
versions. Use them here too.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git.pm: fix cat_blob crashes on large files

Read and write each 1024 byte buffer, rather than trying to buffer
the entire content of the file.  We are only copying the contents to
a file descriptor and do not use it ourselves.

Previous code would crash on all files > 2 Gib, when the offset
variable became negative (perhaps below the level of perl),
resulting in a crash.  On a 32 bit system, or a system with low
memory it might crash before reaching 2 GiB due to memory
exhaustion.

This code may leave a partial file behind in case of failure, where
the old code would leave a completely empty file.  Neither version
verifies the correctness of the content.  Calling code must take
care of verification and cleanup.

Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff-options: unconfuse description of --color

It said "by default it is off" while it also said "the default is
always", which confused everybody who read it only once.  It wanted
to say (1) if you do not say --color, it is not enabled, and (2) if
you say --color but do not say when to enable it, it will always be
enabled".

Rephrase to clarify by using "default" only once.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
branch: segfault fixes and validation

branch_get() can return NULL (so far on detached HEAD only) but some
code paths in builtin/branch.c cannot deal with that and cause
segfaults.

While at there, make sure to bail out when the user gives 2 or more
branches with --set-upstream-to or --unset-upstream, where only the
first branch is processed and the rest silently dropped.

Reported-by: Per Cederqvist <cederp@opera.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
update-index: list supported idx versions and their features

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
update-index: allow "-h" to also display options

Even though "git update-index" was updated to use parse-options
infrastracture some time ago to make it possible to show list of
options with usage_with_options(), "git update-index -h" only shows
the usage.  Detect this case and call usage_with_options() to show
the list of options as well.

Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff: Fix rename pretty-print when suffix and prefix overlap

When considering a rename for two files that have a suffix and a prefix
that can overlap, a confusing line is shown. As an example, renaming
"a/b/b/c" to "a/b/c" shows "a/b/{ => }/b/c".

Currently, what we do is calculate the common prefix ("a/b/"), and the
common suffix ("/b/c"), but the same "/b/" is actually counted both in
prefix and suffix. Then when calculating the size of the non-common part,
we end-up with a negative value which is reset to 0, thus the "{ => }".

Do not allow the common suffix to overlap the common prefix and stop
when reaching a "/" that would be in both.

Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/githooks: Explain pre-rebase parameters

Descriptions borrowed from templates/hooks--pre-rebase.sample.

Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-sh-setup: use a lowercase "usage:" string

mergetool, bisect, and other commands that use
git-sh-setup print a usage string that is inconsistent
with the rest of Git when they are invoked as "git $cmd -h".

The compiled builtins use the lowercase "usage:" string
but these commands say "Usage:".  Adjust the shell library
to make these consistent.

Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>