merge: a random object may not necssarily be a commit

The user could have said "git merge $(git rev-parse v1.0.0)"; we
shouldn't mark it as "Merge commit '15999998fb...'" as the merge
name, even though such an invocation might be crazy.

We could even read the "tag " header from the tag object and replace
the object name the user gave us, but let's not lose the information
by doing so, at least not yet.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move commit GPG signature verification to commit.c

Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit.c/GPG signature verification: Also look at the first GPG status line

Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge/pull: verify GPG signatures of commits being merged

When --verify-signatures is specified on the command-line of git-merge
or git-pull, check whether the commits being merged have good gpg
signatures and abort the merge in case they do not. This allows e.g.
auto-deployment from untrusted repo hosts.

Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email: use "return;" not "return undef;" on error codepaths

All the callers of "ask", "extract_valid_address", and "validate_patch"
subroutines assign the return values from them to a single scalar:

	$var = subr(...);

and "return undef;" in these subroutine can safely be turned into a
simpler "return;".  Doing so will also future-proof a new caller that
mistakenly does this:

    @foo = ask(...);
    if (@foo) { ... we got an answer ... } else { ... we did not ... }

Note that we leave "return undef;" in validate_address on purpose,
even though Perlcritic may complain.  The primary "return" site of
the function returns whatever is in the scalar variable $address, so
it is pointless to change only the other "return undef;" to "return".
The caller must be prepared to see an array with a single undef as
the return value from this subroutine anyway.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email: drop misleading function prototype

The subroutine check_file_rev_conflict() is called from two places,
both of which expects to pass a single scalar variable and see if
that can be interpreted as a pathname or a revision name.  It is
defined with a function prototype ($) to force a scalar context
while evaluating the arguments at the calling site but it does not
help the current calling sites.  The only effect it has is to hurt
future calling sites that may want to build an argument list in an
array variable and call it as check_file_rev_confict(@args).

Drop the misleading prototype, as Perlcritic suggests.

While at it, rename the function to avoid new call sites unaware of
this change arising and add a comment clarifying what this function
is for.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email: use the three-arg form of open in recipients_cmd

Perlcritic does not want to see the trailing pipe in the two-args
form of open(), i.e.

	open my $fh, "$cmd \Q$file\E |";

If $cmd were a single-token command name, it would make a lot more
sense to use four-or-more-args form "open FILEHANDLE,MODE,CMD,ARGS"
to avoid shell from expanding metacharacters in $file, but we do
expect multi-word string in $to_cmd and $cc_cmd to be expanded by
the shell, so we cannot rewrite it to

	open my $fh, "-|", $cmd, $file;

for extra safety.  At least, by using this in the three-arg form:

	open my $fh, "-|", "$cmd \Q$file\E";

we can silence Perlcritic, even though we do not gain much safety by
doing so.

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge/pull Check for untrusted good GPG signatures

When --verify-signatures is specified, abort the merge in case a good
GPG signature from an untrusted key is encountered.

Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty printing: extend %G? to include 'N' and 'U'

Expand %G? in pretty format strings to 'N' in case of no GPG signature
and 'U' in case of a good but untrusted GPG signature in addition to
the previous 'G'ood and 'B'ad. This eases writing anyting parsing
git-log output.

Signed-off-by: Sebastian Götte <jaseg@physik-pool.tu-berlin.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6200: use test_config/test_unconfig

The tests were already well protected from previous ones by running
"git config --unset" on variables early they do not want to see, but
it is easier to make sure they start from a clean state by using
more modern test_config/test_unconfig helper functions.

It turns out that the last test depended on the merge.summary
configuration previous one leaves behind.  Set it explicitly in it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6200: test message for merging of an annotated tag

Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule deinit: clarify work tree removal message

The output of "git submodule deinit sub" of a populated submodule prints

  rm 'sub'

as the first line unless used with the -f option.

The "rm 'sub'" line is exactly the same output the user gets when using
"git rm sub" (because that command is used with the --dry-run option under
the hood to determine if the submodule is clean), which can easily lead to
the false impression that the submodule would be permanently removed. Also
users might be confused that the "rm 'submodule'" line won't show up when
the -f option is used, as the test is skipped in this case.

Silence the "rm 'submodule'" output by using the --quiet option for "git
rm" and always print

  Cleared directory 'submodule'

instead as the first output line. This line is printed as long as the
directory exists, no matter if empty or not.

Also extend the tests in t7400 to make sure the "Cleared directory" line
is printed correctly.

Reported-by: Phil Hord <phil.hord@gmail.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rev-parse: clarify documentation for the --verify option

The old version could be read to mean that the argument has to refer
to a valid object, but that is incorrect:

* the object is not necessarily read (e.g., to check for corruption)

* if the argument is a 40-digit string of hex digits, then it is
  accepted whether or not is is the name of an existing object.

So reword the explanation to be less ambiguous.

Also fix the examples involving --verify: to be sure that the argument
refers to a commit (rather than some other kind of object), the
argument has to be suffixed with "^{commit}".  This trick is not
possible in the example involving --default, so don't imply that it is
exactly the same as the previous example.

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/merge-tag-object'

"git merge $(git rev-parse v1.8.2)" behaved quite differently from
"git merge v1.8.2" as if v1.8.2 were written as v1.8.2^0 and did
not pay much attention to the annotated tag payload.

This makes the code notice the type of the tag object, in addition
to the dwim_ref() based classification the current code uses
(i.e. the name appears in refs/tags/) to decide when to special
case merging of tags.

* jc/merge-tag-object:
  t6200: test message for merging of an annotated tag
  t6200: use test_config/test_unconfig
  merge: a random object may not necssarily be a commit
Merge branch 'rr/send-email-perl-critique'

Update "git send-email" for issues noticed by PerlCritic.

* rr/send-email-perl-critique:
  send-email: use the three-arg form of open in recipients_cmd
  send-email: drop misleading function prototype
  send-email: use "return;" not "return undef;" on error codepaths
Merge branch 'jl/submodule-deinit'

A finishing touch to the new topic in 1.8.3.

* jl/submodule-deinit:
  submodule deinit: clarify work tree removal message
Merge branch 'sg/gpg-sig'

Teach "merge/pull" to optionally verify and reject commits that are
not signed properly.

* sg/gpg-sig:
  pretty printing: extend %G? to include 'N' and 'U'
  merge/pull Check for untrusted good GPG signatures
  merge/pull: verify GPG signatures of commits being merged
  commit.c/GPG signature verification: Also look at the first GPG status line
  Move commit GPG signature verification to commit.c
Merge branch 'mh/rev-parse-verify-doc'

"rev-parse --verify" was documented in a misleading way.

* mh/rev-parse-verify-doc:
  rev-parse: clarify documentation for the --verify option
Update draft release notes to 1.8.3

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