Skip to main content

Browse the archive

https://github.com/git/git
05 April 2024, 19:32:26 UTC
sort by:
Revision Author Date Message Commit Date
19981da Junio C Hamano 05 April 2024, 17:49:37 UTC The fifteenth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 05 April 2024, 17:49:49 UTC
dce1e0b Junio C Hamano 05 April 2024, 17:49:49 UTC Merge branch 'jk/core-comment-string' core.commentChar used to be limited to a single byte, but has been updated to allow an arbitrary multi-byte sequence. * jk/core-comment-string: config: add core.commentString config: allow multi-byte core.commentChar environment: drop comment_line_char compatibility macro wt-status: drop custom comment-char stringification sequencer: handle multi-byte comment characters when writing todo list find multi-byte comment chars in unterminated buffers find multi-byte comment chars in NUL-terminated strings prefer comment_line_str to comment_line_char for printing strbuf: accept a comment string for strbuf_add_commented_lines() strbuf: accept a comment string for strbuf_commented_addf() strbuf: accept a comment string for strbuf_stripspace() environment: store comment_line_char as a string strbuf: avoid shadowing global comment_line_char name commit: refactor base-case of adjust_comment_line_char() strbuf: avoid static variables in strbuf_add_commented_lines() strbuf: simplify comment-handling in add_lines() helper config: forbid newline as core.commentChar 05 April 2024, 17:49:49 UTC
3256584 Junio C Hamano 05 April 2024, 17:49:49 UTC Merge branch 'rs/config-comment' "git config" learned "--comment=<message>" option to leave a comment immediately after the "variable = value" on the same line in the configuration file. * rs/config-comment: config: allow tweaking whitespace between value and comment config: fix --comment formatting config: add --comment option to add a comment 05 April 2024, 17:49:49 UTC
7774cfe Junio C Hamano 03 April 2024, 17:55:20 UTC The fourteenth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 03 April 2024, 17:56:20 UTC
17381ab Junio C Hamano 03 April 2024, 17:56:20 UTC Merge branch 'bl/cherry-pick-empty' Allow git-cherry-pick(1) to automatically drop redundant commits via a new `--empty` option, similar to the `--empty` options for git-rebase(1) and git-am(1). Includes a soft deprecation of `--keep-redundant-commits` as well as some related docs changes and sequencer code cleanup. * bl/cherry-pick-empty: cherry-pick: add `--empty` for more robust redundant commit handling cherry-pick: enforce `--keep-redundant-commits` incompatibility sequencer: do not require `allow_empty` for redundant commit options sequencer: handle unborn branch with `--allow-empty` rebase: update `--empty=ask` to `--empty=stop` docs: clean up `--empty` formatting in git-rebase(1) and git-am(1) docs: address inaccurate `--empty` default with `--exec` 03 April 2024, 17:56:20 UTC
d988e80 Junio C Hamano 03 April 2024, 17:56:20 UTC Merge branch 'bl/pretty-shorthand-config-fix' The "--pretty=<shortHand>" option of the commands in the "git log" family, defined as "[pretty] shortHand = <expansion>" should have been looked up case insensitively, but was not, which has been corrected. * bl/pretty-shorthand-config-fix: pretty: find pretty formats case-insensitively pretty: update tests to use `test_config` 03 April 2024, 17:56:20 UTC
4cc302e Junio C Hamano 03 April 2024, 17:56:20 UTC Merge branch 'rs/strbuf-expand-bad-format' Code clean-up. * rs/strbuf-expand-bad-format: cat-file: use strbuf_expand_bad_format() factor out strbuf_expand_bad_format() 03 April 2024, 17:56:20 UTC
f046355 Junio C Hamano 03 April 2024, 17:56:19 UTC Merge branch 'rs/midx-use-strvec-pushf' Code clean-up. * rs/midx-use-strvec-pushf: midx: use strvec_pushf() for pack-objects base name 03 April 2024, 17:56:20 UTC
188e942 Junio C Hamano 03 April 2024, 17:56:19 UTC Merge branch 'pb/test-scripts-are-build-targets' The t/README file now gives a hint on running individual tests in the "t/" directory with "make t<num>-*.sh t<num>-*.sh". * pb/test-scripts-are-build-targets: t/README: mention test files are make targets 03 April 2024, 17:56:19 UTC
e4193dc Junio C Hamano 03 April 2024, 17:56:19 UTC Merge branch 'ds/grep-doc-updates' Documentation updates. * ds/grep-doc-updates: grep docs: describe --no-index further and improve formatting a bit grep docs: describe --recurse-submodules further and improve formatting a bit 03 April 2024, 17:56:19 UTC
e76218c Junio C Hamano 03 April 2024, 17:56:19 UTC Merge branch 'az/grep-group-error-message-update' Error message clarification. * az/grep-group-error-message-update: grep: improve errors for unmatched ( and ) 03 April 2024, 17:56:19 UTC
eda72dd Junio C Hamano 03 April 2024, 17:56:19 UTC Merge branch 'jc/release-notes-entry-experiment' Introduce an experimental protocol for contributors to propose the topic description to be used in the "What's cooking" report, the merge commit message for the topic, and in the release notes and document it in the SubmittingPatches document. * jc/release-notes-entry-experiment: SubmittingPatches: release-notes entry experiment 03 April 2024, 17:56:19 UTC
e139bb1 Junio C Hamano 03 April 2024, 17:56:18 UTC Merge branch 'jk/remote-helper-object-format-option-fix' The implementation and documentation of "object-format" option exchange between the Git itself and its remote helpers did not quite match, which has been corrected. * jk/remote-helper-object-format-option-fix: transport-helper: send "true" value for object-format option transport-helper: drop "object-format <algo>" option transport-helper: use write helpers more consistently 03 April 2024, 17:56:18 UTC
c2cbfbd Junio C Hamano 01 April 2024, 20:21:22 UTC The thirteenth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 01 April 2024, 20:21:36 UTC
cebe702 Junio C Hamano 01 April 2024, 20:21:35 UTC Merge branch 'ps/clone-with-includeif-onbranch' An additional test to demonstrate that clone would not choke on a global configuration file that uses includeIf.onbranch:*.path. * ps/clone-with-includeif-onbranch: t5601: exercise clones with "includeIf.*.onbranch" 01 April 2024, 20:21:36 UTC
f949703 Junio C Hamano 01 April 2024, 20:21:35 UTC Merge branch 'jk/rebase-apply-leakfix' Leakfix. * jk/rebase-apply-leakfix: rebase: use child_process_clear() to clean 01 April 2024, 20:21:35 UTC
f0c570e Junio C Hamano 01 April 2024, 20:21:35 UTC Merge branch 'ps/t7800-variable-interpolation-fix' Fix the way recently added tests interpolate variables defined outside them, and document the best practice to help future developers. * ps/t7800-variable-interpolation-fix: t/README: document how to loop around test cases t7800: use single quotes for test bodies t7800: improve test descriptions with empty arguments 01 April 2024, 20:21:35 UTC
6938b35 Junio C Hamano 01 April 2024, 20:21:35 UTC Merge branch 'ps/reftable-unit-test-nfs-workaround' A unit test for reftable code tried to enumerate all files in a directory after reftable operations and expected to see nothing but the files it wanted to leave there, but was fooled by .nfs* cruft files left, which has been corrected. * ps/reftable-unit-test-nfs-workaround: reftable: fix tests being broken by NFS' delete-after-close semantics 01 April 2024, 20:21:35 UTC
50b52ca Junio C Hamano 01 April 2024, 20:21:34 UTC Merge branch 'jk/doc-remote-helpers-markup-fix' Documentation mark-up fix. * jk/doc-remote-helpers-markup-fix: doc/gitremote-helpers: fix more missing single-quotes 01 April 2024, 20:21:34 UTC
ac16f55 Junio C Hamano 01 April 2024, 20:21:34 UTC Merge branch 'pb/advice-merge-conflict' Hints that suggest what to do after resolving conflicts can now be squelched by disabling advice.mergeConflict. Acked-by: Phillip Wood <phillip.wood123@gmail.com> cf. <e040c631-42d9-4501-a7b8-046f8dac6309@gmail.com> * pb/advice-merge-conflict: builtin/am: allow disabling conflict advice sequencer: allow disabling conflict advice 01 April 2024, 20:21:34 UTC
521df68 Junio C Hamano 01 April 2024, 20:21:34 UTC Merge branch 'ds/config-internal-whitespace-fix' "git config" corrupted literal HT characters written in the configuration file as part of a value, which has been corrected. * ds/config-internal-whitespace-fix: config.txt: describe handling of whitespace further t1300: add more tests for whitespace and inline comments config: really keep value-internal whitespace verbatim config: minor addition of whitespace 01 April 2024, 20:21:34 UTC
a031815 Junio C Hamano 01 April 2024, 20:21:33 UTC Merge branch 'jk/pretty-subject-cleanup' Code clean-up in the "git log" machinery that implements custom log message formatting. * jk/pretty-subject-cleanup: format-patch: fix leak of empty header string format-patch: simplify after-subject MIME header handling format-patch: return an allocated string from log_write_email_headers() log: do not set up extra_headers for non-email formats pretty: drop print_email_subject flag pretty: split oneline and email subject printing shortlog: stop setting pp.print_email_subject 01 April 2024, 20:21:34 UTC
ccdc7d9 Junio C Hamano 01 April 2024, 20:21:33 UTC Merge branch 'pw/checkout-conflict-errorfix' "git checkout --conflict=bad" reported a bad conflictStyle as if it were given to a configuration variable; it has been corrected to report that the command line option is bad. * pw/checkout-conflict-errorfix: checkout: fix interaction between --conflict and --merge checkout: cleanup --conflict=<style> parsing merge options: add a conflict style member merge-ll: introduce LL_MERGE_OPTIONS_INIT xdiff-interface: refactor parsing of merge.conflictstyle 01 April 2024, 20:21:33 UTC
d6fd043 Junio C Hamano 28 March 2024, 21:13:37 UTC The twelfth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 28 March 2024, 21:13:51 UTC
20d1adb Junio C Hamano 28 March 2024, 21:13:51 UTC Merge branch 'jk/drop-hg-to-git' Remove an ancient and not well maintained Hg-to-git migration script from contrib/. Acked-by: Stelian Pop <stelian@popies.net> cf. <37e4cd61-b370-437e-bd42-f98f47d3ad32@popies.net> * jk/drop-hg-to-git: contrib: drop hg-to-git script 28 March 2024, 21:13:51 UTC
8e24223 Junio C Hamano 28 March 2024, 21:13:51 UTC Merge branch 'rs/t-prio-queue-fixes' Test clean-up. * rs/t-prio-queue-fixes: t-prio-queue: check result array bounds t-prio-queue: shorten array index message 28 March 2024, 21:13:51 UTC
b31d466 Junio C Hamano 28 March 2024, 21:13:51 UTC Merge branch 'bt/fuzz-config-parse' A new fuzz target that exercises config parsing code has been added. * bt/fuzz-config-parse: fuzz: add fuzzer for config parsing 28 March 2024, 21:13:51 UTC
bf0a352 Junio C Hamano 28 March 2024, 21:13:50 UTC Merge branch 'jc/show-untracked-false' The status.showUntrackedFiles configuration variable had a name that tempts users to set a Boolean value expressed in our usual "false", "off", and "0", but it only took "no". This has been corrected so "true" and its synonyms are taken as "normal", while "false" and its synonyms are taken as "no". * jc/show-untracked-false: status: allow --untracked=false and friends status: unify parsing of --untracked= and status.showUntrackedFiles 28 March 2024, 21:13:50 UTC
396430b Junio C Hamano 28 March 2024, 21:13:50 UTC Merge branch 'ph/diff-src-dst-prefix-config' "git diff" and friends learned two extra configuration variables, diff.srcPrefix and diff.dstPrefix. * ph/diff-src-dst-prefix-config: diff.*Prefix: use camelCase in the doc and test titles diff: add diff.srcPrefix and diff.dstPrefix configuration variables 28 March 2024, 21:13:50 UTC
1002f28 Junio C Hamano 28 March 2024, 21:13:50 UTC Merge branch 'eb/hash-transition' Work to support a repository that work with both SHA-1 and SHA-256 hash algorithms has started. * eb/hash-transition: (30 commits) t1016-compatObjectFormat: add tests to verify the conversion between objects t1006: test oid compatibility with cat-file t1006: rename sha1 to oid test-lib: compute the compatibility hash so tests may use it builtin/ls-tree: let the oid determine the output algorithm object-file: handle compat objects in check_object_signature tree-walk: init_tree_desc take an oid to get the hash algorithm builtin/cat-file: let the oid determine the output algorithm rev-parse: add an --output-object-format parameter repository: implement extensions.compatObjectFormat object-file: update object_info_extended to reencode objects object-file-convert: convert commits that embed signed tags object-file-convert: convert commit objects when writing object-file-convert: don't leak when converting tag objects object-file-convert: convert tag objects when writing object-file-convert: add a function to convert trees between algorithms object: factor out parse_mode out of fast-import and tree-walk into in object.h cache: add a function to read an OID of a specific algorithm tag: sign both hashes commit: export add_header_signature to support handling signatures on tags ... 28 March 2024, 21:13:50 UTC
9ccf3e9 Jeff King 27 March 2024, 08:19:22 UTC config: add core.commentString The core.commentChar code recently learned to accept more than a single ASCII character. But using it is annoying with multiple versions of Git, since older ones will reject it outright: $ git.v2.44.0 -c core.commentchar=foo stripspace -s error: core.commentChar should only be one ASCII character fatal: unable to parse 'core.commentchar' from command-line config Let's add an alias core.commentString. That's arguably a better name anyway, since we now can handle strings, and it makes it possible to have a config that works reasonably with both old and new versions of Git (see the example in the documentation). This is strictly an alias, so there's not much point in adding duplicate tests; I added a single one to t0030 that exercises the alias code. Note also that the error messages for invalid values will now show the variable the config parser handed us, and thus will be normalized to lowercase (rather than camelcase). A few tests in t0030 are adjusted to match. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 27 March 2024, 15:48:54 UTC
d255105 Junio C Hamano 25 March 2024, 22:21:45 UTC SubmittingPatches: release-notes entry experiment The "What's cooking" report lists the topics in flight, with a short paragraph descibing what they are about. Once written, the description is automatically picked up from the "What's cooking" report and used in the commit log message of the merge commit when the topic is merged into integration branches. These commit log messges of the merge commits are then propagated to the release notes. It has been the maintainer's task to prepare these entries in the "What's cooking" report. Even though the original author of a topic may be in the best position to write the initial description of a topic, we so far lacked a formal channel for the author to suggest what description to use. The usual procedure has been for the author to see the topic described in "What's cooking" report, and then either complain about inaccurate explanation and/or offer a rewrite. Let's try an experiment to optionally let the author propose the one paragraph description when the topic is submitted. Pick the cover letter as the logical place to do so, and describe an experimental workflow in the SubmittingPatches document. Signed-off-by: Junio C Hamano <gitster@pobox.com> 26 March 2024, 16:37:15 UTC
ec79d76 Brian Lyles 25 March 2024, 23:16:54 UTC cherry-pick: add `--empty` for more robust redundant commit handling As with git-rebase(1) and git-am(1), git-cherry-pick(1) can result in a commit being made redundant if the content from the picked commit is already present in the target history. However, git-cherry-pick(1) does not have the same options available that git-rebase(1) and git-am(1) have. There are three things that can be done with these redundant commits: drop them, keep them, or have the cherry-pick stop and wait for the user to take an action. git-rebase(1) has the `--empty` option added in commit e98c4269c8 (rebase (interactive-backend): fix handling of commits that become empty, 2020-02-15), which handles all three of these scenarios. Similarly, git-am(1) got its own `--empty` in 7c096b8d61 (am: support --empty=<option> to handle empty patches, 2021-12-09). git-cherry-pick(1), on the other hand, only supports two of the three possiblities: Keep the redundant commits via `--keep-redundant-commits`, or have the cherry-pick fail by not specifying that option. There is no way to automatically drop redundant commits. In order to bring git-cherry-pick(1) more in-line with git-rebase(1) and git-am(1), this commit adds an `--empty` option to git-cherry-pick(1). It has the same three options (keep, drop, and stop), and largely behaves the same. The notable difference is that for git-cherry-pick(1), the default will be `stop`, which maintains the current behavior when the option is not specified. Like the existing `--keep-redundant-commits`, `--empty=keep` will imply `--allow-empty`. The `--keep-redundant-commits` option will be documented as a deprecated synonym of `--empty=keep`, and will be supported for backwards compatibility for the time being. Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 23:45:41 UTC
bd2f9fd Brian Lyles 25 March 2024, 23:16:53 UTC cherry-pick: enforce `--keep-redundant-commits` incompatibility When `--keep-redundant-commits` was added in b27cfb0d8d (git-cherry-pick: Add keep-redundant-commits option, 2012-04-20), it was not marked as incompatible with the various operations needed to continue or exit a cherry-pick (`--continue`, `--skip`, `--abort`, and `--quit`). Enforce this incompatibility via `verify_opt_compatible` like we do for the other various options. Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 23:45:41 UTC
661b671 Brian Lyles 25 March 2024, 23:16:52 UTC sequencer: do not require `allow_empty` for redundant commit options A consumer of the sequencer that wishes to take advantage of either the `keep_redundant_commits` or `drop_redundant_commits` feature must also specify `allow_empty`. However, these refer to two distinct types of empty commits: - `allow_empty` refers specifically to commits which start empty - `keep_redundant_commits` refers specifically to commits that do not start empty, but become empty due to the content already existing in the target history Conceptually, there is no reason that the behavior for handling one of these should be entangled with the other. It is particularly unintuitive to require `allow_empty` in order for `drop_redundant_commits` to have an effect: in order to prevent redundant commits automatically, initially-empty commits would need to be kept automatically as well. Instead, rewrite the `allow_empty()` logic to remove the over-arching requirement that `allow_empty` be specified in order to reach any of the keep/drop behaviors. Only if the commit was originally empty will `allow_empty` have an effect. Note that no behavioral changes should result from this commit -- it merely sets the stage for future commits. In one such future commit, an `--empty` option will be added to git-cherry-pick(1), meaning that `drop_redundant_commits` will be used by that command. Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 23:45:40 UTC
1b90588 Brian Lyles 25 March 2024, 23:16:51 UTC sequencer: handle unborn branch with `--allow-empty` When using git-cherry-pick(1) with `--allow-empty` while on an unborn branch, an error is thrown. This is inconsistent with the same cherry-pick when `--allow-empty` is not specified. Detect unborn branches in `is_index_unchanged`. When on an unborn branch, use the `empty_tree` as the tree to compare against. Add a new test to cover this scenario. While modelled off of the existing 'cherry-pick on unborn branch' test, some improvements can be made: - Use `git switch --orphan unborn` instead of `git checkout --orphan unborn` to avoid the need for a separate `rm -rf *` call - Avoid using `--quiet` in the `git diff` call to make debugging easier in the event of a failure. Use simply `--exit-code` instead. Make these improvements to the existing test as well as the new test. Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 23:45:40 UTC
c282eba Brian Lyles 25 March 2024, 23:16:50 UTC rebase: update `--empty=ask` to `--empty=stop` When git-am(1) got its own `--empty` option in 7c096b8d61 (am: support --empty=<option> to handle empty patches, 2021-12-09), `stop` was used instead of `ask`. `stop` is a more accurate term for describing what really happens, and consistency is good. Update git-rebase(1) to also use `stop`, while keeping `ask` as a deprecated synonym. Update the tests to primarily use `stop`, but also ensure that `ask` is still allowed. In a future commit, we'll be adding a new `--empty` option for git-cherry-pick(1) as well, making the consistency even more relevant. Reported-by: Elijah Newren <newren@gmail.com> Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 23:45:40 UTC
64a443e Brian Lyles 25 March 2024, 23:16:49 UTC docs: clean up `--empty` formatting in git-rebase(1) and git-am(1) Both of these pages document very similar `--empty` options, but with different styles. The exact behavior of these `--empty` options differs somewhat, but consistent styling in the docs is still beneficial. This commit aims to make them more consistent. Break the possible values for `--empty` into separate sections for readability. Alphabetical order is chosen for consistency. In a future commit, we'll be documenting a new `--empty` option for git-cherry-pick(1), making the consistency even more relevant. Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 23:45:40 UTC
0af3889 Brian Lyles 25 March 2024, 23:16:48 UTC docs: address inaccurate `--empty` default with `--exec` The documentation for git-rebase(1) indicates that using the `--exec` option will use `--empty=drop`. This is inaccurate: when `--interactive` is not explicitly provided, `--exec` results in `--empty=keep` behaviors. Correctly indicate the behavior of `--exec` using `--empty=keep` when `--interactive` is not specified. Reported-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 23:45:40 UTC
c75fd8d Junio C Hamano 25 March 2024, 23:16:20 UTC The eleventh batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 23:16:35 UTC
03658df Junio C Hamano 25 March 2024, 23:16:35 UTC Merge branch 'bl/doc-key-val-sep-fix' The documentation for "%(trailers[:options])" placeholder in the "--pretty" option of commands in the "git log" family has been updated. * bl/doc-key-val-sep-fix: docs: adjust trailer `separator` and `key_value_separator` language docs: correct trailer `key_value_separator` description 25 March 2024, 23:16:35 UTC
b58cc6a Junio C Hamano 25 March 2024, 23:16:35 UTC Merge branch 'bl/doc-config-fixes' A few typoes in "git config --help" have been corrected. * bl/doc-config-fixes: docs: fix typo in git-config `--default` docs: clarify file options in git-config `--edit` 25 March 2024, 23:16:35 UTC
0cb25d1 Junio C Hamano 25 March 2024, 23:16:34 UTC Merge branch 'ja/doc-formatting-fix' Documentation mark-up fix. * ja/doc-formatting-fix: doc: fix some placeholders formating doc: format alternatives in synopsis 25 March 2024, 23:16:34 UTC
a7f0fcb Junio C Hamano 25 March 2024, 23:16:34 UTC Merge branch 'bb/sh-scripts-cleanup' Shell scripts clean-up. * bb/sh-scripts-cleanup: (22 commits) git-quiltimport: avoid an unnecessary subshell contrib/coverage-diff: avoid redundant pipelines t/t9*: merge "grep | sed" pipelines t/t8*: merge "grep | sed" pipelines t/t5*: merge a "grep | sed" pipeline t/t4*: merge a "grep | sed" pipeline t/t3*: merge a "grep | awk" pipeline t/t1*: merge a "grep | sed" pipeline t/t9*: avoid redundant uses of cat t/t8*: avoid redundant use of cat t/t7*: avoid redundant use of cat t/t6*: avoid redundant uses of cat t/t5*: avoid redundant uses of cat t/t4*: avoid redundant uses of cat t/t3*: avoid redundant uses of cat t/t1*: avoid redundant uses of cat t/t0*: avoid redundant uses of cat t/perf: avoid redundant use of cat t/annotate-tests.sh: avoid redundant use of cat t/lib-cvs.sh: avoid redundant use of cat ... 25 March 2024, 23:16:34 UTC
46d8bf3 Junio C Hamano 25 March 2024, 23:16:34 UTC Merge branch 'jc/index-pack-fsck-levels' Test fix. * jc/index-pack-fsck-levels: t5300: fix test_with_bad_commit() 25 March 2024, 23:16:34 UTC
d921c36 Junio C Hamano 25 March 2024, 23:16:34 UTC Merge branch 'js/bugreport-no-suffix-fix' "git bugreport --no-suffix" was not supported and instead segfaulted, which has been corrected. * js/bugreport-no-suffix-fix: bugreport.c: fix a crash in `git bugreport` with `--no-suffix` option 25 March 2024, 23:16:34 UTC
199074f Junio C Hamano 25 March 2024, 23:16:33 UTC Merge branch 'rj/restore-plug-leaks' Leaks from "git restore" have been plugged. * rj/restore-plug-leaks: checkout: plug some leaks in git-restore 25 March 2024, 23:16:33 UTC
6e9ef29 Dragan Simic 25 March 2024, 20:34:53 UTC grep docs: describe --no-index further and improve formatting a bit Improve the description of --no-index, to make it more clear to the users what this option actually does under the hood, and what's its purpose. Describe the dependency between --no-index and either of the --cached and --untracked options, which cannot be used together. As part of that, shuffle a couple of the options, to make the documentation flow a bit better, because it makes more sense to describe first the options that have something in common, and to after that describe an option that does something differently. In more detail, --cached and --untracked both leave git-grep(1) in the usual state, in which it treats the directory as a local git repository, unlike --no-index that makes git-grep(1) treat the directory not as a git repository. While there, improve the descriptions of grep worker threads a bit, to give them better context. Adjust the language a bit, to avoid addressing the reader directly, which is in general preferred in technical documentation, because it eliminates the possible element of persuading the user to do something. In other words, we should be telling the user what our software can do, instead of telling the user what to do. Also perform some minor formatting improvements, to make it clear it's the git commands, command parameters, and configuration option names. Signed-off-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 21:00:03 UTC
4a9357a Dragan Simic 25 March 2024, 20:34:52 UTC grep docs: describe --recurse-submodules further and improve formatting a bit Clarify that --recurse-submodules cannot be used together with --untracked, and improve the formatting in a couple of places, to make it visually clear that those are the commands or the names of configuration options. While there, change a couple of "<tree>" placeholders to "_<tree>_", to help with an ongoing translation improvement effort. [1] [1] https://lore.kernel.org/git/CAPig+cQc8W4JOpB+TMP=czketU1U7wcY_x9bsP5T=3-XjGLhRQ@mail.gmail.com/ Signed-off-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 21:00:03 UTC
f999d51 Brian Lyles 25 March 2024, 07:25:13 UTC pretty: find pretty formats case-insensitively User-defined pretty formats are stored in config, which is meant to use case-insensitive matching for names as noted in config.txt's 'Syntax' section: All the other lines [...] are recognized as setting variables, in the form 'name = value' [...]. The variable names are case-insensitive, [...]. When a user specifies one of their format aliases with an uppercase in it, however, it is not found. $ git config pretty.testAlias %h $ git config --list | grep pretty pretty.testalias=%h $ git log --format=testAlias -1 fatal: invalid --pretty format: testAlias $ git log --format=testalias -1 3c2a3fdc38 This is true whether the name in the config file uses any uppercase characters or not. Use case-insensitive comparisons when identifying format aliases. Co-authored-by: Jeff King <peff@peff.net> Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 19:19:48 UTC
2cd134f Brian Lyles 25 March 2024, 07:25:12 UTC pretty: update tests to use `test_config` These tests use raw `git config` calls, which is an older style that can cause config to bleed between tests if not manually unset. `test_config` ensures that config is unset at the end of each test automatically. `test_config` is chosen over `git -c` since `test_config` still ends up calling `git config` which seems slightly more realistic to how pretty formats would be defined normally. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 19:19:45 UTC
4d45e79 René Scharfe 24 March 2024, 16:40:00 UTC midx: use strvec_pushf() for pack-objects base name Build the pack base name argument directly using strvec_pushf() instead of with an intermediate strbuf. This is shorter, simpler and avoids the need for explicit cleanup. Signed-off-by: René Scharfe <l.s.r@web.de> Reviewed-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 19:03:27 UTC
8d38380 Philippe Blain 24 March 2024, 15:14:05 UTC t/README: mention test files are make targets Since 23fc63bf8f (make tests ignorable with "make -i", 2005-11-08), each test file defines a target in the test Makefile, such that one can invoke: make *checkout* to run all tests with 'checkout' in their filename. This is useful to run a subset of tests when you have a good idea of what part of the code is touched by the changes your are testing. Document that in t/README to help new (or more seasoned) contributors that might not be aware. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 18:59:48 UTC
7c43bdf René Scharfe 24 March 2024, 11:21:15 UTC cat-file: use strbuf_expand_bad_format() Report unknown format elements and missing closing parentheses with consistent and translated messages by calling strbuf_expand_bad_format() at the very end of the combined if/else chain of expand_format() and expand_atom(). Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 18:59:26 UTC
e36091a René Scharfe 24 March 2024, 11:19:40 UTC factor out strbuf_expand_bad_format() Extract a function for reporting placeholders that are not enclosed in a parenthesis or are unknown. This reduces the number of strings to translate and improves consistency across commands. Call it at the end of the if/else chain, after exhausting all accepted possibilities. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 18:59:24 UTC
0d52784 Ahelenia Ziemiańska 23 March 2024, 13:18:08 UTC grep: improve errors for unmatched ( and ) Imagine you want to grep for (. Easy: $ git grep '(' fatal: unmatched parenthesis uhoh. This is plainly wrong. Unless you know specifically that (a) git grep has expression groups and '(' ... ')' are used for them. (b) you can use -e '(' to explicitly say '(' is what you are looking for, not the beginning of a group. Similarly, $ git grep ')' fatal: incomplete pattern expression: ) is somehow worse. ")" is a complete regular expression pattern. Of course, the error wants to say "group" here. In this case it is also not "incomplete", it is unmatched. Make them say $ ./git grep '(' fatal: unmatched ( for expression group $ ./git grep ')' fatal: incomplete pattern expression group: ) which are clearer in indicating that it is not the expression that is wrong (since no pattern had been parsed at all), but rather that it is been misconstrued as a grouping operator. Link: https://bugs.debian.org/1051205 Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Signed-off-by: Junio C Hamano <gitster@pobox.com> 25 March 2024, 18:40:53 UTC
647e870 Jeff King 22 March 2024, 10:35:02 UTC rebase: use child_process_clear() to clean In the run_am() function, we set up a child_process struct to run "git-am", allocating memory for its args and env strvecs. These are normally cleaned up when we call run_command(). But if we encounter certain errors, we exit the function early and try to clean up ourselves by clearing the am.args field. This leaks the "env" strvec. We should use child_process_clear() instead, which covers both. And more importantly, it future proofs us against the struct ever growing more allocated fields. These are unlikely errors to happen in practice, so they don't actually trigger the leak sanitizer in the tests. But we can add a new test which does exercise one of the paths (and fails SANITIZE=leak without this patch). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 March 2024, 17:21:35 UTC
1c10b8e Jeff King 22 March 2024, 09:59:51 UTC format-patch: fix leak of empty header string The log_write_email_headers() function recently learned to return the "extra_headers_p" variable to the caller as an allocated string. We start by copying rev_info.extra_headers into a strbuf, and then detach the strbuf at the end of the function. If there are no extra headers, we leave the strbuf empty. Likewise, if there are no headers to return, we pass back NULL. This misses a corner case which can cause a leak. The "do we have any headers to copy" check is done by looking for a NULL opt->extra_headers. But the "do we have a non-empty string to return" check is done by checking the length of the strbuf. That means if opt->extra_headers is the empty string, we'll "copy" it into the strbuf, triggering an allocation, but then leak the buffer when we return NULL from the function. We can solve this in one of two ways: 1. Rather than checking headers->len at the end, we could check headers->alloc to see if we allocated anything. That retains the original behavior before the recent change, where an empty extra_headers string is "passed through" to the caller. In practice this doesn't matter, though (the code which eventually looks at the result treats NULL or the empty string the same). 2. Only bother copying a non-empty string into the strbuf. This has the added bonus of avoiding a pointless allocation. Arguably strbuf_addstr() could do this optimization itself, though it may be slightly dangerous to do so (some existing callers may not get a fresh allocation when they expect to). In theory callers are all supposed to use strbuf_detach() in such a case, but there's no guarantee that this is the case. This patch uses option 2. Without it, building with SANITIZE=leak shows many errors in t4021 and elsewhere. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 March 2024, 16:50:53 UTC
7c4449e Patrick Steinhardt 22 March 2024, 02:23:46 UTC t/README: document how to loop around test cases In some cases it makes sense to loop around test cases so that we can execute the same test with slightly different arguments. There are some gotchas around quoting here though that are easy to miss and that may lead to easy-to-miss errors and portability issues. Document the proper way to do this in "t/README". Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 March 2024, 14:36:35 UTC
c559677 Patrick Steinhardt 22 March 2024, 02:23:41 UTC t7800: use single quotes for test bodies In eb84c8b6ce (git-difftool--helper: honor `--trust-exit-code` with `--dir-diff`, 2024-02-20) we have started to loop around some of the tests in t7800 so that they are reexecuted with slightly different arguments. As part of that refactoring the quoting of test bodies was changed from single quotes (') to double quotes (") so that the value of the loop variable is accessible to the body. As the test body is later on passed to eval this change was not required though. Let's revert it back to use single quotes as usual in our tests. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 March 2024, 14:36:34 UTC
ac45f68 Patrick Steinhardt 22 March 2024, 02:23:36 UTC t7800: improve test descriptions with empty arguments Some of the tests in t7800 are executed repeatedly in a loop with different arguments. To distinguish these tests, the value of that variable is rendered into the test title. But given that one of the values is the empty string, it results in a somewhat awkward test name: difftool ignores exit code Improve this by printing "without options" in case the value is empty. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 22 March 2024, 14:36:34 UTC
e6895c3 Dragan Simic 21 March 2024, 06:06:08 UTC config.txt: describe handling of whitespace further Make it more clear what the whitespace characters are in the context of git configuration files, and significantly improve the description of the leading and trailing whitespace handling, especially how it works out together with the presence of inline comments. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 March 2024, 22:57:10 UTC
d71bc1b Dragan Simic 21 March 2024, 06:06:07 UTC t1300: add more tests for whitespace and inline comments Add a handful of additional tests, to improve the coverage of the handling of configuration file entries whose values contain internal whitespace, leading and/or trailing whitespace, which may or may not be enclosed within quotation marks, or which contain an additional inline comment. At the same time, rework one already existing whitespace-related test a bit, to ensure its consistency with the newly added tests. This change introduced no functional changes to the already existing test. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 March 2024, 22:57:10 UTC
f0b8944 Dragan Simic 21 March 2024, 06:06:06 UTC config: really keep value-internal whitespace verbatim Fix a bug in function parse_value() that prevented whitespace characters (i.e. spaces and horizontal tabs) found inside configuration option values from being parsed and returned in their original form. The bug caused any number of consecutive whitespace characters to be wrongly "squashed" into the same number of space characters. This bug was introduced back in July 2009, in commit ebdaae372b46 ("config: Keep inner whitespace verbatim"). Further investigation showed that setting a configuration value, by invoking git-config(1), converts value-internal horizontal tabs into "\t" escape sequences, which the buggy value-parsing logic in function parse_value() didn't "squash" into spaces. That's why the test included in the ebdaae37 commit passed, which presumably made the bug remain undetected for this long. On the other hand, value-internal literal horizontal tab characters, found in a configuration file edited by hand, do get "squashed" by the value-parsing logic, so the right choice was to fix this bug by making the value-internal whitespace characters preserved verbatim. Signed-off-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 March 2024, 22:57:09 UTC
0d49b1e Dragan Simic 21 March 2024, 06:06:05 UTC config: minor addition of whitespace In general, binary operators should be enclosed in a pair of leading and trailing space (SP) characters. Thus, clean up one spotted expression that for some reason had a "bunched up" operator. Signed-off-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 March 2024, 22:57:09 UTC
11c821f Junio C Hamano 21 March 2024, 21:54:56 UTC The tenth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 March 2024, 21:55:14 UTC
e577fec Junio C Hamano 21 March 2024, 21:55:14 UTC Merge branch 'bb/t0006-negative-tz-offset' More tests on showing time with negative TZ offset. * bb/t0006-negative-tz-offset: t0006: add more tests with a negative TZ offset 21 March 2024, 21:55:14 UTC
1f49f75 Junio C Hamano 21 March 2024, 21:55:14 UTC Merge branch 'bb/iso-strict-utc' The output format for dates "iso-strict" has been tweaked to show a time in the Zulu timezone with "Z" suffix, instead of "+00:00". * bb/iso-strict-utc: date: make "iso-strict" conforming for the UTC timezone 21 March 2024, 21:55:14 UTC
6e70114 Junio C Hamano 21 March 2024, 21:55:14 UTC Merge branch 'jw/doc-show-untracked-files-fix' The status.showUntrackedFiles configuration variable was incorrectly documented to accept "false", which has been corrected. * jw/doc-show-untracked-files-fix: doc: status.showUntrackedFiles does not take "false" 21 March 2024, 21:55:14 UTC
509a047 Junio C Hamano 21 March 2024, 21:55:13 UTC Merge branch 'dg/user-manual-hash-example' User manual (the original one) update. * dg/user-manual-hash-example: Documentation/user-manual.txt: example for generating object hashes 21 March 2024, 21:55:14 UTC
81ba11b Junio C Hamano 21 March 2024, 21:55:13 UTC Merge branch 'ja/doc-markup-fixes' Mark-ups used in the documentation has been improved for consistency. * ja/doc-markup-fixes: doc: git-clone: format placeholders doc: git-clone: format verbatim words doc: git-init: rework config item init.templateDir doc: git-init: rework definition lists doc: git-init: format placeholders doc: git-init: format verbatim parts 21 March 2024, 21:55:13 UTC
b0b43e3 Junio C Hamano 21 March 2024, 21:55:13 UTC Merge branch 'pb/ci-win-artifact-names-fix' CI update. * pb/ci-win-artifact-names-fix: ci(github): make Windows test artifacts name unique 21 March 2024, 21:55:13 UTC
e8c1cda Junio C Hamano 21 March 2024, 21:55:13 UTC Merge branch 'ps/reftable-reflog-iteration-perf' The code to iterate over reflogs in the reftable has been optimized to reduce memory allocation and deallocation. Reviewed-by: Josh Steadmon <steadmon@google.com> cf. <Ze9eX-aaWoVaqsPP@google.com> * ps/reftable-reflog-iteration-perf: refs/reftable: track last log record name via strbuf reftable/record: use scratch buffer when decoding records reftable/record: reuse message when decoding log records reftable/record: reuse refnames when decoding log records reftable/record: avoid copying author info reftable/record: convert old and new object IDs to arrays refs/reftable: reload correct stack when creating reflog iter 21 March 2024, 21:55:13 UTC
dc97afd Junio C Hamano 21 March 2024, 21:55:13 UTC Merge branch 'jc/safe-implicit-bare' Users with safe.bareRepository=explicit can still work from within $GIT_DIR of a seconary worktree (which resides at .git/worktrees/$name/) of the primary worktree without explicitly specifying the $GIT_DIR environment variable or the --git-dir=<path> option. * jc/safe-implicit-bare: setup: notice more types of implicit bare repositories 21 March 2024, 21:55:13 UTC
8be51c1 Junio C Hamano 21 March 2024, 21:55:12 UTC Merge branch 'fs/find-end-of-log-message-fix' The code to find the effective end of log message can fall into an endless loop, which has been corrected. * fs/find-end-of-log-message-fix: wt-status: don't find scissors line beyond buf len 21 March 2024, 21:55:12 UTC
3eba921 Junio C Hamano 21 March 2024, 21:55:12 UTC Merge branch 'ps/reftable-block-search-fix' The reftable code has its own custom binary search function whose comparison callback has an unusual interface, which caused the binary search to degenerate into a linear search, which has been corrected. * ps/reftable-block-search-fix: reftable/block: fix binary search over restart counter reftable/record: fix memory leak when decoding object records 21 March 2024, 21:55:12 UTC
330ed38 Junio C Hamano 21 March 2024, 21:55:12 UTC Merge branch 'ps/reftable-stack-tempfile' The code in reftable backend that creates new table files works better with the tempfile framework to avoid leaving cruft after a failure. * ps/reftable-stack-tempfile: reftable/stack: register compacted tables as tempfiles reftable/stack: register lockfiles during compaction reftable/stack: register new tables as tempfiles lockfile: report when rollback fails 21 March 2024, 21:55:12 UTC
7a01b44 Junio C Hamano 21 March 2024, 21:55:12 UTC Merge branch 'rs/opt-parse-long-fixups' The parse-options code that deals with abbreviated long option names have been cleaned up. Reviewed-by: Josh Steadmon <steadmon@google.com> cf. <ZfDM5Or3EKw7Q9SA@google.com> * rs/opt-parse-long-fixups: parse-options: rearrange long_name matching code parse-options: normalize arg and long_name before comparison parse-options: detect ambiguous self-negation parse-options: factor out register_abbrev() and struct parsed_option parse-options: set arg of abbreviated option lazily parse-options: recognize abbreviated negated option with arg 21 March 2024, 21:55:12 UTC
0068aa7 Patrick Steinhardt 21 March 2024, 15:39:52 UTC reftable: fix tests being broken by NFS' delete-after-close semantics It was reported that the reftable unit tests in t0032 fail with the following assertion when running on top of NFS: running test_reftable_stack_compaction_concurrent_clean reftable/stack_test.c: 1063: failed assertion count_dir_entries(dir) == 2 Aborted Setting a breakpoint immediately before the assertion in fact shows the following list of files: ./stack_test-1027.QJBpnd ./stack_test-1027.QJBpnd/0x000000000001-0x000000000003-dad7ac80.ref ./stack_test-1027.QJBpnd/.nfs000000000001729f00001e11 ./stack_test-1027.QJBpnd/tables.list Note the weird ".nfs*" file? This file is maintained by NFS clients in order to emulate delete-after-last-close semantics that we rely on in the reftable code [1]. Instead of unlinking the file right away and keeping it open in the client, the NFS client will rename it to ".nfs*" and then delete that temporary file when the last reference to it gets dropped. Quoting the NFS FAQ: > D2. What is a "silly rename"? Why do these .nfsXXXXX files keep > showing up? > > A. Unix applications often open a scratch file and then unlink it. > They do this so that the file is not visible in the file system name > space to any other applications, and so that the system will > automatically clean up (delete) the file when the application exits. > This is known as "delete on last close", and is a tradition among > Unix applications. > > Because of the design of the NFS protocol, there is no way for a > file to be deleted from the name space but still remain in use by an > application. Thus NFS clients have to emulate this using what > already exists in the protocol. If an open file is unlinked, an NFS > client renames it to a special name that looks like ".nfsXXXXX". > This "hides" the file while it remains in use. This is known as a > "silly rename." Note that NFS servers have nothing to do with this > behavior. This of course throws off the assertion that we got exactly two files in that directory. The test in question triggers this behaviour by holding two open file descriptors to the "tables.list" file. One of the references is because we are about to append to the stack, whereas the other reference is because we want to compact it. As the compaction has just finished we already rewrote "tables.list" to point to the new contents, but the other file descriptor pointing to the old version is still open. Thus we trigger the delete-after-last-close emulation. Furthermore, it was reported that this behaviour only triggers with 4f36b8597c (reftable/stack: fix race in up-to-date check, 2024-01-18). This is expected as well because it is the first point in time where we actually keep the "tables.list" file descriptor open for the stat cache. Fix this bug by skipping over any files that start with a leading dot when counting files. While we could explicitly check for a prefix of ".nfs", other network file systems like SMB for example do the same trickery but with a ".smb" prefix. In any case though, this loosening of the assertion should be fine given that the reftable library would never write files with leading dots by itself. [1]: https://nfs.sourceforge.net/#faq_d2 Reported-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com> 21 March 2024, 17:32:21 UTC
ba155b5 Jeff King 20 March 2024, 09:48:24 UTC contrib: drop hg-to-git script The hg-to-git script is full of command injection vulnerabilities against malicious branch and tag names. It's also old and largely unmaintained; the last commit was over 4 years ago, and the last code change before that was from 2013. Users are better off with a modern remote-helper tool like cinnabar or remote-hg. So rather than spending time to fix it, let's just get rid of it. Reported-by: Matthew Rollings <admin@stealthcopter.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 March 2024, 17:23:45 UTC
b5b7b17 Jeff King 20 March 2024, 09:41:03 UTC transport-helper: send "true" value for object-format option The documentation in gitremote-helpers.txt claims that after a helper has advertised the "object-format" capability, Git may then send "option object-format true" to indicate that it would like to hear which object format the helper is using when it returns refs. However, the code implementing this has always written just "option object-format", without the extra "true" value. Nobody noticed in practice or in the tests because the only two helpers we ship are: - remote-curl, which quietly converts missing values into "true". This goes all the way back to ef08ef9ea0 (remote-helpers: Support custom transport options, 2009-10-30), despite the fact that I don't think any other option has ever made use of it. - remote-testgit in t5801 does insist on having a "true" value. But since it sends the ":object-format" response regardless of whether it thinks the caller asked for it (technically breaking protocol), everything just works, albeit with an extra shell error: .../git/t/t5801/git-remote-testgit: 150: test: =: unexpected operator printed to stderr, which you can see running t5801 with --verbose. (The problem is that $val is the empty string, and since we don't double-quote it in "test $val = true", we invoke "test = true" instead). When the documentation and code do not match, it is often good to fix the documentation rather than break compatibility. And in this case, we have had the mis-match since 8b85ee4f47 (transport-helper: implement object-format extensions, 2020-05-25). However, the sha256 feature was listed as experimental until 8e42eb0e9a (doc: sha256 is no longer experimental, 2023-07-31). It's possible there are some third party helpers that tried to follow the documentation, and are broken. Changing the code will fix them. It's also possible that there are ones that follow the code and will be broken if we change it. I suspect neither is the case given that no helper authors have brought this up as an issue (I only noticed it because I was running t5801 in verbose mode for other reasons and wondered about the weird shell error). That, coupled with the relative new-ness of sha256, makes me think nobody has really worked on helpers for it yet, which gives us an opportunity to correct the code before too much time passes. And doing so has some value: it brings "object-format" in line with the syntax of other options, making the protocol more consistent. It also lets us use set_helper_option(), which has better error reporting. Note that we don't really need to allow any other values like "false" here. The point is for Git to tell the helper that it understands ":object-format" lines coming back as part of the ref listing. There's no point in future versions saying "no, I don't understand that". To make sure everything works as expected, we can improve the remote-testgit helper from t5801 to send the ":object-format" line only if the other side correctly asked for it (which modern Git will always do). With that test change and without the matching code fix here, t5801 will fail when run with GIT_TEST_DEFAULT_HASH=sha256. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 March 2024, 17:01:30 UTC
d6f6b43 Jeff King 20 March 2024, 09:37:40 UTC transport-helper: drop "object-format <algo>" option The documentation in gitremote-helpers.txt claims that helpers should accept an object-format option from Git whose value is either: 1. "true", in which case the helper is merely told that Git understands the special ":object-format" response, and will send it 2. an algorithm name that the helper should use However, Git has never sent the second form, and it's not clear if it would ever be useful. When interacting with a remote Git repository, we generally discover what _their_ object format is, and then decide what to do with a mismatch (where that is currently just "bail out", but could eventually be on-the-fly conversion and interop). And that is true for native protocols, but also for transport helpers like remote-curl that talk to remote Git repositories. There we send back an ":object-format" line telling Git what remote-curl detected on the other side. And this is true even for pushes (since we get it via receive-pack's advertisement). And it is even true for dumb-http, as we guess at the algorithm based on the hash size, due to ac093d0790 (remote-curl: detect algorithm for dumb HTTP by size, 2020-06-19). The one case where it _isn't_ true is dumb-http talking to an empty repository. There we have no clue what the remote hash is, so remote-curl just sends back its default. If we kept the "object-format <algo>" form then in theory Git could say "object-format sha256" to change that default. But it doesn't really accomplish anything. We still may or may not be mis-matched with the other side. For a fetch that's OK, since it's by definition a noop. For a push into an empty repository, it might matter (though the dumb http-push DAV code seems happy to clobber a remote sha256 info/refs and corrupt the repository). If we want to pursue making this work, I think we'd be better off improving detection of the object format of empty repositories over dumb-http (e.g., an "info/object-format" file). But what about helpers that _aren't_ talking to another Git repo? Consider something like git-cinnabar, which is converting on the fly to/from hg. Most of the heavy lifting is done by fast-import/export, but some oids may still pass between Git and the helper. Could "object-format <algo>" be useful to tell the helper what oids we expect to see? Possibly, but in practice this isn't necessary. Git-cinnabar for example already peeks at the local-repo .git/config to check its object-format (and currently just bails if it is sha256). So I think the "object-format" extension really is only useful for the helper telling Git what object-format it found, and not the other way around. Note that this patch can't break any remote helpers; we're not changing the code on the Git side at all, but just bringing the documentation in line with what Git has always done. It does remove the receiving support in remote-curl.c, but that code was never actually triggered. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 March 2024, 17:01:27 UTC
cf7335f Jeff King 20 March 2024, 09:34:17 UTC transport-helper: use write helpers more consistently The transport-helper code provides some functions for writing to the helper process, but there are a few spots that don't use them. We should do so consistently because: 1. They detect errors on write (though in practice this means the helper process went away, and we'd see the problem as soon as we try to read the response). 2. They dump the written bytes to the GIT_TRANSPORT_HELPER_DEBUG stream. It's doubly confusing to miss some writes but not others, as you see a partial conversation. The "list" ones go all the way back to the beginning of the transport helper code; they were just missed when most writes were converted in bf3c523c3f (Add remote helper debug mode, 2009-12-09). The nearby "object-format" write presumably just cargo-culted them, as it's only a few lines away. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 March 2024, 17:00:55 UTC
9dc75d8 Jeff King 20 March 2024, 09:17:48 UTC doc/gitremote-helpers: fix more missing single-quotes There are a few cases left in gitremote-helpers.txt that are missing a closing quote, so you end up with: 'option deepen-since <timestamp> with a stray opening quote instead of rendering correctly in italics. These should have been part of 51d41dc243 (doc/gitremote-helpers: fix missing single-quote, 2024-03-07), but apparently my eyesight is not what it once was. Hopefully this is now all of them. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 March 2024, 16:53:09 UTC
838ba01 Jeff King 20 March 2024, 00:35:57 UTC format-patch: simplify after-subject MIME header handling In log_write_email_headers(), we append our MIME headers to the set of extra headers by creating a new strbuf, adding the existing headers, and then adding our new ones. We had to do it this way when our output buffer might point to the constant opt->extra_headers variable. But since the previous commit, we always make a local copy of that variable. Let's turn that into a strbuf, which lets the MIME code simply append to it. That simplifies the function and avoids a pointless extra copy of the headers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 March 2024, 00:54:16 UTC
305a681 Jeff King 20 March 2024, 00:35:33 UTC format-patch: return an allocated string from log_write_email_headers() When pretty-printing a commit in the email format, we have to fill in the "after subject" field of the pretty_print_context with any extra headers the user provided (e.g., from "--to" or "--cc" options) plus any special MIME headers. We return an out-pointer that sometimes points to a newly heap-allocated string and sometimes not. To avoid leaking, we store the allocated version in a buffer with static lifetime, which is ugly. Worse, as we extend the header feature, we'll end up having to repeat this ugly pattern. Instead, let's have our out-pointer pass ownership back to the caller, and duplicate the string when necessary. This does mean one extra allocation per commit when you use extra headers, but in the context of format-patch which is showing diffs, I don't think that's even measurable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 March 2024, 00:54:16 UTC
82363d9 Jeff King 20 March 2024, 00:31:39 UTC log: do not set up extra_headers for non-email formats The commit pretty-printer code has an "after_subject" parameter which it uses to insert extra headers into the email format. In show_log() we set this by calling log_write_email_headers() if we are using an email format, but otherwise default the variable to the rev_info.extra_headers variable. Since the pretty-printer code will ignore after_subject unless we are using an email format, this default is pointless. We can just set after_subject directly, eliminating an extra variable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 March 2024, 00:54:16 UTC
d5a90d6 Jeff King 20 March 2024, 00:30:44 UTC pretty: drop print_email_subject flag With one exception, the print_email_subject flag is set if and only if the commit format is email based: - in make_cover_letter() we set it along with CMIT_FMT_EMAIL explicitly - in show_log(), we set it if cmit_fmt_is_mail() is true. That covers format-patch as well as "git log --format=email" (or mboxrd). The one exception is "rev-list --format=email", which somewhat nonsensically prints the author and date as email headers, but no subject, like: $ git rev-list --format=email HEAD commit 64fc4c2cdd4db2645eaabb47aa4bac820b03cdba From: Jeff King <peff@peff.net> Date: Tue, 19 Mar 2024 19:39:26 -0400 this is the subject this is the body It's doubtful that this is a useful format at all (the "commit" lines replace the "From" lines that would make it work as an actual mbox). But I think that printing the subject as a header (like this patch does) is the least surprising thing to do. So let's drop this field, making the code a little simpler and easier to reason about. Note that we do need to set the "rev" field of the pretty_print_context in rev-list, since that is used to check for subject_prefix, etc. It's not possible to set those fields via rev-list, so we'll always just print "Subject: ". But unless we pass in our rev_info, fmt_output_email_subject() would segfault trying to figure it out. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 March 2024, 00:54:15 UTC
69aff62 Jeff King 20 March 2024, 00:28:51 UTC pretty: split oneline and email subject printing The pp_title_line() function is used for two formats: the oneline format and the subject line of the email format. But most of the logic in the function does not make any sense for oneline; it is about special formatting of email headers. Lumping the two formats together made sense long ago in 4234a76167 (Extend --pretty=oneline to cover the first paragraph, 2007-06-11), when there was a lot of manual logic to paste lines together. But later, 88c44735ab (pretty: factor out format_subject(), 2008-12-27) pulled that logic into its own function. We can implement the oneline format by just calling that one function. This makes the intention of the code much more clear, as we know we only need to worry about those extra email options when dealing with actual email. While the intent here is cleanup, it is possible to trigger these cases in practice by running format-patch with an explicit --oneline option. But if you did, the results are basically nonsense. For example, with the preserve_subject flag: $ printf "%s\n" one two three | git commit --allow-empty -F - $ git format-patch -1 --stdout -k | grep ^Subject Subject: =?UTF-8?q?one=0Atwo=0Athree?= $ git format-patch -1 --stdout -k --oneline --no-signature 2af7fbe one two three Or with extra headers: $ git format-patch -1 --stdout --cc=me --oneline --no-signature 2af7fbe one two three Cc: me So I'd actually consider this to be an improvement, though you are probably crazy to use other formats with format-patch in the first place (arguably it should forbid non-email formats entirely, but that's a bigger change). As a bonus, it eliminates some pointless extra allocations for the oneline output. The email code, since it has to deal with wrapping, formats into an extra auxiliary buffer. The speedup is tiny, though like "rev-list --no-abbrev --format=oneline" seems to improve by a consistent 1-2% for me. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 March 2024, 00:54:15 UTC
c7f6a53 Jeff King 20 March 2024, 00:27:16 UTC shortlog: stop setting pp.print_email_subject When shortlog processes a commit using its internal traversal, it may pretty-print the subject line for the summary view. When we do so, we set the "print_email_subject" flag in the pretty-print context. But this flag does nothing! Since we are using CMIT_FMT_USERFORMAT, we skip most of the usual formatting code entirely. This flag is there due to commit 6d167fd7cc (pretty: use fmt_output_email_subject(), 2017-03-01). But that just switched us away from setting an empty "subject" header field, which was similarly useless. That was added by dd2e794a21 (Refactor pretty_print_commit arguments into a struct, 2009-10-19). Before using the struct, we had to pass _something_ as the argument, so we passed the empty string (a NULL would have worked equally well). So this setting has never done anything, and we can drop the line. That shortens the code, but more importantly, makes it easier to reason about and refactor the other users of this flag. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 20 March 2024, 00:54:15 UTC
3bd955d Junio C Hamano 18 March 2024, 20:02:12 UTC The ninth batch Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 March 2024, 20:04:25 UTC
d2e4e26 Junio C Hamano 18 March 2024, 20:04:25 UTC Merge branch 'jk/doc-remote-helpers-markup-fix' Doc mark-up fix. * jk/doc-remote-helpers-markup-fix: doc/gitremote-helpers: fix missing single-quote 18 March 2024, 20:04:25 UTC
7f1e926 Junio C Hamano 18 March 2024, 20:04:25 UTC Merge branch 'jh/trace2-missing-def-param-fix' Some trace2 events that lacked def_param have learned to show it, enriching the output. Reviewed-by: Josh Steadmon <steadmon@google.com> cf. <ZejkVOVQBZhLVfHW@google.com> * jh/trace2-missing-def-param-fix: trace2: emit 'def_param' set with 'cmd_name' event trace2: avoid emitting 'def_param' set more than once t0211: demonstrate missing 'def_param' events for certain commands 18 March 2024, 20:04:25 UTC
184969c Junio C Hamano 18 March 2024, 20:04:25 UTC Merge branch 'pw/rebase-i-ignore-cherry-pick-help-environment' Code simplification by getting rid of code that sets an environment variable that is no longer used. * pw/rebase-i-ignore-cherry-pick-help-environment: rebase -i: stop setting GIT_CHERRY_PICK_HELP 18 March 2024, 20:04:25 UTC
bff85a3 Brian Lyles 18 March 2024, 05:38:02 UTC docs: adjust trailer `separator` and `key_value_separator` language The language describing the trailer separator and key-value separator default value is overly complicated. Indicate the default with simpler "Defaults to ..." language. Suggested-by: Linus Arver <linusa@google.com> Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Acked-by: Linus Arver <linusa@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 March 2024, 16:36:00 UTC
cb85ed1 Brian Lyles 18 March 2024, 05:38:01 UTC docs: correct trailer `key_value_separator` description The description for `key_value_separator` incorrectly states that this separator is inserted between trailer lines, which appears likely to have been incorrectly copied from `separator` when this option was added. Update the description to correctly indicate that it is a separator that appears between the key and the value of each trailer. Signed-off-by: Brian Lyles <brianmlyles@gmail.com> Acked-by: Linus Arver <linusa@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 March 2024, 16:35:49 UTC
37ce973 Philippe Blain 16 March 2024, 21:16:30 UTC builtin/am: allow disabling conflict advice When 'git am' or 'git rebase --apply' encounter a conflict, they show a message instructing the user how to continue the operation. This message can't be disabled. Use ADVICE_MERGE_CONFLICT introduced in the previous commit to allow disabling it. Update the tests accordingly, as the advice output is now on stderr instead of stdout. In t4150, redirect stdout to 'out' and stderr to 'err', since this is less confusing. In t4254, as we are testing a specific failure mode of 'git am', simply disable the advice. Note that we are not testing that this advice is shown in 'git rebase' for the apply backend since 2ac0d6273f (rebase: change the default backend from "am" to "merge", 2020-02-15). Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 March 2024, 16:28:42 UTC
ec03009 Philippe Blain 16 March 2024, 21:16:29 UTC sequencer: allow disabling conflict advice Allow disabling the advice shown when a squencer operation results in a merge conflict through a new config 'advice.mergeConflict', which is named generically such that it can be used by other commands eventually. Remove that final '\n' in the first hunk in sequencer.c to avoid an otherwise empty 'hint: ' line before the line 'hint: Disable this message with "git config advice.mergeConflict false"' which is automatically added by 'advise_if_enabled'. Note that we use 'advise_if_enabled' for each message in the second hunk in sequencer.c, instead of using 'if (show_hints && advice_enabled(...)', because the former instructs the user how to disable the advice, which is more user-friendly. Update the tests accordingly. Note that the body of the second test in t3507-cherry-pick-conflict.sh is enclosed in double quotes, so we must escape them in the added line. Note that t5520-pull.sh, which checks that we display the advice for 'git rebase' (via 'git pull --rebase') does not have to be updated because it only greps for a specific line in the advice message. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 March 2024, 16:28:40 UTC
30ff050 René Scharfe 16 March 2024, 21:09:47 UTC t-prio-queue: check result array bounds Avoid reading past the end of the "result" array, which could otherwise happen if the prio-queue were to yield more items than were put into it due to an implementation bug, or if the array has not enough entries due to a test bug. Also check at the end whether all "result" entries were consumed, which would not be the case if the prio-queue forgot some entries or the test definition contained too many. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 March 2024, 16:25:54 UTC
e6f9cb7 René Scharfe 16 March 2024, 20:45:51 UTC t-prio-queue: shorten array index message If we get an unexpected result, the prio-queue unit test reports it like this: # check "result[j++] == show(get)" failed at t/unit-tests/t-prio-queue.c:43 # left: 5 # right: 1 # failed at result[] index 0 That last line repeats "failed" and "result" from the first line. Shorten it to resemble a similar one in t-ctype and also remove the incrementation from the first line to avoid possible distractions from the message of which comparison went wrong where: # check "result[j] == show(get)" failed at t/unit-tests/t-prio-queue.c:43 # left: 5 # right: 1 # j: 0 Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 18 March 2024, 16:24:50 UTC
back to top