git/pretty.c, branch v2.36.2

Merge branch 'es/pretty-describe-more'

2021-12-15T17:39:48Z

Extend "git log --format=%(describe)" placeholder to allow passing selected command-line options to the underlying "git describe" command. * es/pretty-describe-more: pretty: add abbrev option to %(describe) pretty: add tag option to %(describe) pretty.c: rework describe options parsing for better extensibility

Merge branch 'hm/paint-hits-in-log-grep'

2021-11-01T20:48:08Z

"git log --grep=string --author=name" learns to highlight hits just like "git grep string" does. * hm/paint-hits-in-log-grep: grep/pcre2: fix an edge case concerning ascii patterns and UTF-8 data pretty: colorize pattern matches in commit messages grep: refactor next_match() and match_one_pattern() for external use

pretty: add abbrev option to %(describe)

2021-11-01T17:34:36Z

The %(describe) placeholder by default, like `git describe`, uses a seven-character abbreviated commit object name. This may not be sufficient to fully describe all commits in a given repository, resulting in a placeholder replacement changing its length because the repository grew in size. This could cause the output of git-archive to change. Add the --abbrev option to `git describe` to the placeholder interface in order to provide tools to the user for fine-tuning project defaults and ensure reproducible archives. One alternative would be to just always specify --abbrev=40 but this may be a bit too biased... Signed-off-by: Eli Schwartz Signed-off-by: Junio C Hamano

pretty: add tag option to %(describe)

2021-11-01T17:34:34Z

The %(describe) placeholder by default, like `git describe`, only supports annotated tags. However, some people do use lightweight tags for releases, and would like to describe those anyway. The command line tool has an option to support this. Teach the placeholder to support this as well. Signed-off-by: Eli Schwartz Signed-off-by: Junio C Hamano

pretty.c: rework describe options parsing for better extensibility

2021-11-01T17:34:32Z

It contains option arguments only, not options. We would like to add option support here too, but to do that we need to distinguish between different types of options. Lay out the groundwork for distinguishing between bools, strings, etc. and move the central logic (validating values and pushing new arguments to *args) into the successful match, because that will be fairly conditional on what type of argument is being parsed. Signed-off-by: Eli Schwartz Signed-off-by: Junio C Hamano

Merge branch 'jk/log-warn-on-bogus-encoding'

2021-10-29T22:43:15Z

Squelch over-eager warning message added during this cycle. * jk/log-warn-on-bogus-encoding: log: document --encoding behavior on iconv() failure Revert "logmsg_reencode(): warn when iconv() fails"

Revert "logmsg_reencode(): warn when iconv() fails"

2021-10-29T20:48:58Z

This reverts commit fd680bc5 (logmsg_reencode(): warn when iconv() fails, 2021-08-27). Throwing a warning for each and every commit that gets reencoded, without allowing a way to squelch, would make it unpleasant for folks who have to deal with an ancient part of the history in an old project that used wrong encoding in the commits.

Merge branch 'fs/ssh-signing'

2021-10-25T23:06:58Z

Use ssh public crypto for object and push-cert signing. * fs/ssh-signing: ssh signing: test that gpg fails for unknown keys ssh signing: tests for logs, tags & push certs ssh signing: duplicate t7510 tests for commits ssh signing: verify signatures using ssh-keygen ssh signing: provide a textual signing_key_id ssh signing: retrieve a default key from ssh-agent ssh signing: add ssh key format and signing code ssh signing: add test prereqs ssh signing: preliminary refactoring and clean-up

pretty: colorize pattern matches in commit messages

2021-10-08T21:19:14Z

The "git log" command limits its output to the commits that contain strings matched by a pattern when the "--grep=" option is used, but unlike output from "git grep -e ", the matches are not highlighted, making them harder to spot. Teach the pretty-printer code to highlight matches from the "--grep=", "--author=" and "--committer=" options (to view the last one, you may have to ask for --pretty=fuller). Also, it must be noted that we are effectively greping the content twice (because it would be a hassle to rework the existing matching code to do a /g match and then pass it all down to the coloring code), however it only slows down "git log --author=^H" on this repository by around 1-2% (compared to v2.33.0), so it should be a small enough slow down to justify the addition of the feature. Signed-off-by: Hamza Mahfooz Signed-off-by: Junio C Hamano

ssh signing: preliminary refactoring and clean-up

2021-09-10T21:15:51Z

Openssh v8.2p1 added some new options to ssh-keygen for signature creation and verification. These allow us to use ssh keys for git signatures easily. In our corporate environment we use PIV x509 Certs on Yubikeys for email signing/encryption and ssh keys which I think is quite common (at least for the email part). This way we can establish the correct trust for the SSH Keys without setting up a separate GPG Infrastructure (which is still quite painful for users) or implementing x509 signing support for git (which lacks good forwarding mechanisms). Using ssh agent forwarding makes this feature easily usable in todays development environments where code is often checked out in remote VMs / containers. In such a setup the keyring & revocationKeyring can be centrally generated from the x509 CA information and distributed to the users. To be able to implement new signing formats this commit: - makes the sigc structure more generic by renaming "gpg_output" to "output" - introduces function pointers in the gpg_format structure to call format specific signing and verification functions - moves format detection from verify_signed_buffer into the check_signature api function and calls the format specific verify - renames and wraps sign_buffer to handle format specific signing logic as well Signed-off-by: Fabian Stelzer Signed-off-by: Junio C Hamano