git/log-tree.c, branch v2.26.1

Merge branch 'hd/show-one-mergetag-fix'

2020-03-09T18:21:21Z

"git show" and others gave an object name in raw format in its error output, which has been corrected to give it in hex. * hd/show-one-mergetag-fix: show_one_mergetag: print non-parent in hex form.

Merge branch 'hi/gpg-use-check-signature'

2020-03-05T18:43:05Z

"git merge signed-tag" while lacking the public key started to say "No signature", which was utterly wrong. This regression has been reverted. * hi/gpg-use-check-signature: Revert "gpg-interface: prefer check_signature() for GPG verification"

show_one_mergetag: print non-parent in hex form.

2020-03-02T20:34:00Z

When a mergetag names a non-parent, which can occur after a shallow clone, its hash was previously printed as raw data. Print it in hex form instead. Signed-off-by: Harald van Dijk Signed-off-by: Junio C Hamano

Revert "gpg-interface: prefer check_signature() for GPG verification"

2020-02-28T17:43:17Z

This reverts commit 72b006f4bfd30b7c5037c163efaf279ab65bea9c, which breaks the end-user experience when merging a signed tag without having the public key. We should report "can't check because we have no public key", but the code with this change claimed that there was no signature.

sha1-file: pass git_hash_algo to hash_object_file()

2020-01-31T18:45:39Z

Allow hash_object_file() to work on arbitrary repos by introducing a git_hash_algo parameter. Change callers which have a struct repository pointer in their scope to pass on the git_hash_algo from the said repo. For all other callers, pass on the_hash_algo, which was already being used internally at hash_object_file(). This functionality will be used in the following patch to make check_object_signature() be able to work on arbitrary repos (which, in turn, will be used to fix an inconsistency at object.c:parse_object()). Signed-off-by: Matheus Tavares Signed-off-by: Junio C Hamano

Merge branch 'hi/gpg-use-check-signature'

2019-12-10T21:11:45Z

Hide lower-level verify_signed-buffer() API as a pure helper to implement the public check_signature() function, in order to encourage new callers to use the correct and more strict validation. * hi/gpg-use-check-signature: gpg-interface: prefer check_signature() for GPG verification

gpg-interface: prefer check_signature() for GPG verification

2019-11-30T21:52:35Z

This commit refactors the use of verify_signed_buffer() outside of gpg-interface.c to use check_signature() instead. It also turns verify_signed_buffer() into a file-local function since it's now only invoked internally by check_signature(). There were previously two globally scoped functions used in different parts of Git to perform GPG signature verification: verify_signed_buffer() and check_signature(). Now only check_signature() is used. The verify_signed_buffer() function doesn't guard against duplicate signatures as described by Michał Górny [1]. Instead it only ensures a non-erroneous exit code from GPG and the presence of at least one GOODSIG status field. This stands in contrast with check_signature() that returns an error if more than one signature is encountered. The lower degree of verification makes the use of verify_signed_buffer() problematic if callers don't parse and validate the various parts of the GPG status message themselves. And processing these messages seems like a task that should be reserved to gpg-interface.c with the function check_signature(). Furthermore, the use of verify_signed_buffer() makes it difficult to introduce new functionality that relies on the content of the GPG status lines. Now all operations that does signature verification share a single entry point to gpg-interface.c. This makes it easier to propagate changed or additional functionality in GPG signature verification to all parts of Git, without having odd edge-cases that don't perform the same degree of verification. [1] https://dev.gentoo.org/~mgorny/articles/attack-on-git-signature-verification.html Signed-off-by: Hans Jerry Illikainen Signed-off-by: Junio C Hamano

range-diff: pass through --notes to `git log`

2019-11-21T00:29:52Z

When a commit being range-diff'd has a note attached to it, the note will be compared as well. However, if a user has multiple notes refs or if they want to suppress notes from being printed, there is currently no way to do this. Pass through `--[no-]notes[=]` to the `git log` call so that this option is customizable. Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano

Merge branch 'rs/simplify-by-deco-with-deco-refs-exclude'

2019-10-07T02:32:54Z

"git log --decorate-refs-exclude=" was incorrectly overruled when the "--simplify-by-decoration" option is used, which has been corrected. * rs/simplify-by-deco-with-deco-refs-exclude: log-tree: call load_ref_decorations() in get_name_decoration() log: test --decorate-refs-exclude with --simplify-by-decoration

log-tree: call load_ref_decorations() in get_name_decoration()

2019-09-09T18:16:40Z

Load a default set of ref name decorations at the first lookup. This frees direct and indirect callers from doing so. They can still do it if they want to use a filter or are interested in full decorations instead of the default short ones -- the first load_ref_decorations() call wins. This means that the load in builtin/log.c::cmd_log_init_finish() is respected even if --simplify-by-decoration is given, as the previously dominating earlier load in handle_revision_opt() is gone. So a filter given with --decorate-refs-exclude is used for simplification in that case, as expected. Signed-off-by: René Scharfe Signed-off-by: Junio C Hamano