git/builtin/fast-export.c, branch jch

fast-import: add 'abort-if-invalid' mode to '--signed-commits='

2026-03-26T19:42:57Z

The '--signed-commits=' option for git-fast-import(1) configures how signed commits are handled when encountered. In cases where an invalid commit signature is encountered, a user may wish to abort the operation entirely. Introduce an 'abort-if-invalid' mode to do so. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

fast-export: check for unsupported signing modes earlier

2026-03-26T19:42:57Z

The '--signed-{commits,tags}' options for git-fast-export(1) support only a subset of the modes accepted by git-fast-import(1). Unsupported modes such as 'strip-if-invalid' and 'sign-if-invalid' are accepted during option parsing, but cause the command to die later when a signed object is encountered. Instead, reject unsupported signing modes immediately after parsing the option. This treats them the same as other unknown modes and avoids deferring the error until object processing. This also removes duplicated checks in commit/tag handling code. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

fast-import: add mode to sign commits with invalid signatures

2026-03-13T04:28:20Z

With git-fast-import(1), handling of signed commits is controlled via the `--signed-commits=` option. When an invalid signature is encountered, a user may want the option to sign the commit again as opposed to just stripping the signature. To facilitate this, introduce a "sign-if-invalid" mode for the `--signed-commits` option. Optionally, a key ID may be explicitly provided in the form `sign-if-invalid[=]` to specify which signing key should be used when signing invalid commit signatures. Note that to properly support interoperability mode when signing commit signatures, the commit buffer must be created in both the repository and compatability object formats to generate the appropriate signatures accordingly. As currently implemented, the commit buffer for the compatability object format is not reconstructed and thus signing commits in interoperability mode is not yet supported. Support may be added in the future. Signed-off-by: Justin Tobler Signed-off-by: Junio C Hamano

string-list: add string_list_sort_u() that mimics "sort -u"

2026-01-29T17:32:50Z

Many callsites of string_list_remove_duplicates() call it immdediately after calling string_list_sort(), understandably as the former requires string-list to be sorted, it is clear that these places are sorting only to remove duplicates and for no other reason. Introduce a helper function string_list_sort_u that combines these two calls that often appear together, to simplify these callsites. Replace the current calls of those methods with string_list_sort_u(). Signed-off-by: Amisha Chhajed Signed-off-by: Junio C Hamano

Merge branch 'cc/fast-import-strip-if-invalid'

2025-12-05T05:49:58Z

"git fast-import" learns "--strip-if-invalid" option to drop invalid cryptographic signature from objects. * cc/fast-import-strip-if-invalid: fast-import: add 'strip-if-invalid' mode to --signed-commits= commit: refactor verify_commit_buffer() fast-import: refactor finalize_commit_buffer()

fast-import: add 'strip-if-invalid' mode to --signed-commits=

2025-11-26T16:43:44Z

Tools like `git filter-repo`[1] use `git fast-export` and `git fast-import` to rewrite repository history. When rewriting history using one such tool though, commit signatures might become invalid because the commits they sign changed due to the changes in the repository history made by the tool between the fast-export and the fast-import steps. Note that as far as signature handling goes: * Since fast-export doesn't know what changes filter-repo may make to the stream, it can't know whether the signatures will still be valid. * Since filter-repo doesn't know what history canonicalizations fast-export performed (and it performs a few), it can't know whether the signatures will still be valid. * Therefore, fast-import is the only process in the pipeline that can know whether a specified signature remains valid. Having invalid signatures in a rewritten repository could be confusing, so users rewritting history might prefer to simply discard signatures that are invalid at the fast-import step. For example a common use case is to rewrite only "recent" history. While specifying commit ranges corresponding to "recent" commits could work, users worry about getting it wrong and want to just automatically rewrite everything, expecting older commit signatures to be untouched. To let them do that, let's add a new 'strip-if-invalid' mode to the `--signed-commits=` option of `git fast-import`. It would be interesting for the `--signed-tags=` option to have this mode too, but we leave that for a future improvement. It might also be possible for `git fast-export` to have such a mode in its `--signed-commits=` and `--signed-tags=` options, but the use cases for it are much less clear, so we also leave that for possible future improvements. For now let's just die() if 'strip-if-invalid' is passed to these options where it hasn't been implemented yet. [1]: https://github.com/newren/git-filter-repo Helped-by: Elijah Newren Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

Merge branch 'cc/fast-import-export-i18n-cleanup'

2025-11-06T23:17:01Z

Messages from fast-import/export are now marked for i18n. * cc/fast-import-export-i18n-cleanup: gpg-interface: mark a string for translation fast-import: mark strings for translation fast-export: mark strings for translation gpg-interface: use left shift to define GPG_VERIFY_* gpg-interface: simplify ssh fingerprint parsing

fast-export: mark strings for translation

2025-10-30T14:06:58Z

Some error or warning messages in "builtin/fast-export.c" are marked for translation, but many are not. To be more consistent and provide a better experience to people using a translated version, let's mark all the remaining error or warning messages for translation. While at it: - improve how some arguments to some error functions are indented, - remove "Error:" at the start of an error message, - downcase error and warning messages that start with an uppercase. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

fast-export: handle all kinds of tag signatures

2025-10-13T15:51:42Z

Currently the handle_tag() function in "builtin/fast-export.c" searches only for "\n-----BEGIN PGP SIGNATURE-----\n" in the tag message to find a tag signature. This doesn't handle all kinds of OpenPGP signatures as some can start with "-----BEGIN PGP MESSAGE-----" too, and this doesn't handle SSH and X.509 signatures either as they use "-----BEGIN SSH SIGNATURE-----" and "-----BEGIN SIGNED MESSAGE-----" respectively. To handle all these kinds of tag signatures supported by Git, let's use the parse_signed_buffer() function to properly find signatures in tag messages. Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano

gpg-interface: refactor 'enum sign_mode' parsing

2025-09-17T18:18:28Z

The definition of 'enum sign_mode' as well as its parsing code are in "builtin/fast-export.c". This was fine because `git fast-export` was the only command with '--signed-tags=' or '--signed-commits=' options. In a following commit, we are going to add a similar option to `git fast-import`, which will be simpler, easier and cleaner if we can reuse the 'enum sign_mode' defintion and parsing code. So let's move that definition and parsing code from "builtin/fast-export.c" to "gpg-interface.{c,h}". While at it, let's fix a small indentation issue with the arguments of parse_opt_sign_mode(). Signed-off-by: Christian Couder Signed-off-by: Junio C Hamano