https://github.com/git/git

sort by:
Revision Author Date Message Commit Date
c000d91 Git 2.39-rc0 Signed-off-by: Junio C Hamano <gitster@pobox.com> 23 November 2022, 02:22:25 UTC
c197977 Merge branch 'mh/gitcredentials-generate' Doc update. * mh/gitcredentials-generate: Docs: describe how a credential-generating helper works 23 November 2022, 02:22:25 UTC
f8828f9 Merge branch 'ps/receive-use-only-advertised' "git receive-pack" used to use all the local refs as the boundary for checking connectivity of the data "git push" sent, but now it uses only the refs that it advertised to the pusher. In a repository with the .hideRefs configuration, this reduces the resources needed to perform the check. cf. <221028.86bkpw805n.gmgdl@evledraar.gmail.com> cf. <xmqqr0yrizqm.fsf@gitster.g> * ps/receive-use-only-advertised: receive-pack: only use visible refs for connectivity check rev-parse: add `--exclude-hidden=` option revision: add new parameter to exclude hidden refs revision: introduce struct to handle exclusions revision: move together exclusion-related functions refs: get rid of global list of hidden refs refs: fix memory leak when parsing hideRefs config 23 November 2022, 02:22:25 UTC
173fc54 Merge branch 'jt/submodule-on-demand' Push all submodules recursively with '--recurse-submodules=on-demand'. * jt/submodule-on-demand: Doc: document push.recurseSubmodules=only 23 November 2022, 02:22:25 UTC
8d7b35b Merge branch 'sz/macos-fsmonitor-symlinks' Fix an issue where core.fsmonitor on macOS would not notice created or modified symbolic links. * sz/macos-fsmonitor-symlinks: fsmonitor--daemon: on macOS support symlink 23 November 2022, 02:22:25 UTC
a655f28 Merge branch 'ew/delta-islands-free' Free structures related to delta islands after use. * ew/delta-islands-free: delta-islands: free island-related data after use 23 November 2022, 02:22:25 UTC
2fe427e Merge branch 'mg/notes-newline' Avoid a stray empty newline in the template when creating new notes. * mg/notes-newline: notes: avoid empty line in template 23 November 2022, 02:22:25 UTC
032e8da Merge branch 'tb/howto-maintain-git-fixes' A pair of bugfixes to the Documentation/howto/maintain-git.txt guide. * tb/howto-maintain-git-fixes: Documentation: build redo-seen.sh from jch..seen Documentation: build redo-jch.sh from master..jch 23 November 2022, 02:22:24 UTC
cf9721c Merge branch 'es/chainlint-lineno' Teach chainlint.pl to show corresponding line numbers when printing the source of a test. * es/chainlint-lineno: chainlint: prefix annotated test definition with line numbers chainlint: latch line numbers at which each token starts and ends chainlint: sidestep impoverished macOS "terminfo" 23 November 2022, 02:22:24 UTC
ff84d03 Merge branch 'pw/rebase-no-reflog-action' Avoid setting GIT_REFLOG_ACTION to improve readability of the sequencer internals. * pw/rebase-no-reflog-action: rebase: stop exporting GIT_REFLOG_ACTION sequencer: stop exporting GIT_REFLOG_ACTION 23 November 2022, 02:22:24 UTC
4a04f71 Merge branch 'ab/t7610-timeout' Fix a source of flakiness in CI when compiling with SANITIZE=leak. * ab/t7610-timeout: t7610: use "file:///dev/null", not "/dev/null", fixes MinGW t7610: fix flaky timeout issue, don't clone from example.com 23 November 2022, 02:22:24 UTC
56a64fc Merge branch 'rp/maintenance-qol' 'git maintenance register' is taught to write configuration to an arbitrary path, and 'git for-each-repo' is taught to expand tilde characters in paths. * rp/maintenance-qol: builtin/gc.c: fix use-after-free in maintenance_unregister() maintenance --unregister: fix uninit'd data use & -Wdeclaration-after-statement maintenance: add option to register in a specific config for-each-repo: interpolate repo path arguments 23 November 2022, 02:22:24 UTC
3b041ea Merge branch 'pw/strict-label-lookups' Correct an error where `git rebase` would mistakenly use a branch or tag named "refs/rewritten/xyz" when missing a rebase label. * pw/strict-label-lookups: sequencer: tighten label lookups sequencer: unify label lookup 23 November 2022, 02:22:23 UTC
6adf170 Merge branch 'gc/redact-h2h3-headers' Redact headers from cURL's h2h3 module in GIT_CURL_VERBOSE and others. * gc/redact-h2h3-headers: http: redact curl h2h3 headers in info t: run t5551 tests with both HTTP and HTTP/2 23 November 2022, 02:22:23 UTC
4b76998 Merge branch 'ab/coccicheck-incremental' "make coccicheck" is time consuming. It has been made to run more incrementally. * ab/coccicheck-incremental: Makefile: don't create a ".build/.build/" for cocci, fix output spatchcache: add a ccache-alike for "spatch" cocci: run against a generated ALL.cocci cocci rules: remove <id>'s from rules that don't need them Makefile: copy contrib/coccinelle/*.cocci to build/ cocci: optimistically use COMPUTE_HEADER_DEPENDENCIES cocci: make "coccicheck" rule incremental cocci: split off "--all-includes" from SPATCH_FLAGS cocci: split off include-less "tests" from SPATCH_FLAGS Makefile: split off SPATCH_BATCH_SIZE comment from "cocci" heading Makefile: have "coccicheck" re-run if flags change Makefile: add ability to TAB-complete cocci *.patch rules cocci rules: remove unused "F" metavariable from pending rule Makefile + shared.mak: rename and indent $(QUIET_SPATCH_T) 23 November 2022, 02:22:23 UTC
613fb30 Merge branch 'es/chainlint-output' Teach chainlint.pl to annotate the original test definition instead of the token stream. * es/chainlint-output: chainlint: annotate original test definition rather than token stream chainlint: latch start/end position of each token chainlint: tighten accuracy when consuming input stream chainlint: add explanatory comments 23 November 2022, 02:22:23 UTC
58d80df Merge branch 'js/remove-stale-scalar-repos' 'scalar reconfigure -a' is taught to automatically remove scalar.repo entires which no longer exist. * js/remove-stale-scalar-repos: tests(scalar): tighten the stale `scalar.repo` test some scalar reconfigure -a: remove stale `scalar.repo` entries 23 November 2022, 02:22:23 UTC
e3d40fb Merge branch 'dd/bisect-helper-subcommand' Fix a regression in the bisect-helper which mistakenly treats arguments to the command given to 'git bisect run' as arguments to the helper. * dd/bisect-helper-subcommand: bisect--helper: parse subcommand with OPT_SUBCOMMAND bisect--helper: move all subcommands into their own functions bisect--helper: remove unused options 23 November 2022, 02:22:22 UTC
1107a39 Merge branch 'ab/submodule-helper-prep-only' Preparation to remove git-submodule.sh and replace it with a builtin. * ab/submodule-helper-prep-only: submodule--helper: use OPT_SUBCOMMAND() API submodule--helper: drop "update --prefix <pfx>" for "-C <pfx> update" submodule--helper: remove --prefix from "absorbgitdirs" submodule API & "absorbgitdirs": remove "----recursive" option submodule.c: refactor recursive block out of absorb function submodule tests: test for a "foreach" blind-spot submodule--helper: fix a memory leak in "status" submodule tests: add tests for top-level flag output submodule--helper: move "config" to a test-tool 23 November 2022, 02:22:22 UTC
a078951 The thirteenth batch Signed-off-by: Taylor Blau <me@ttaylorr.com> 18 November 2022, 23:48:53 UTC
e87a229 Merge branch 'en/sparse-checkout-design' Design doc. * en/sparse-checkout-design: sparse-checkout.txt: new document with sparse-checkout directions 18 November 2022, 23:44:01 UTC
26734da Merge branch 'jk/branch-delete-detached' Fix a bug where `git branch -d` did not work on an orphaned HEAD. * jk/branch-delete-detached: branch: gracefully handle '-d' on orphan HEAD 18 November 2022, 23:44:00 UTC
35a62bb Merge branch 'mh/credential-unrecognized-attrs' Docfix. * mh/credential-unrecognized-attrs: docs: clarify that credential discards unrecognised attributes 18 November 2022, 23:43:59 UTC
a92fce4 Merge branch 'vd/skip-cache-tree-update' Avoid calling 'cache_tree_update()' when doing so would be redundant. * vd/skip-cache-tree-update: rebase: use 'skip_cache_tree_update' option read-tree: use 'skip_cache_tree_update' option reset: use 'skip_cache_tree_update' option unpack-trees: add 'skip_cache_tree_update' option cache-tree: add perf test comparing update and prime 18 November 2022, 23:43:56 UTC
3f98d7a Merge branch 'mh/increase-credential-cache-timeout' Update the credential-cache documentation to provide a more realistic example. * mh/increase-credential-cache-timeout: Documentation: increase example cache timeout to 1 hour 18 November 2022, 23:43:55 UTC
35dc2cf Merge branch 'vd/update-refs-delete' `git rebase --update-refs` would delete references when all `update-ref` commands in the sequencer were removed, which has been corrected. * vd/update-refs-delete: rebase --update-refs: avoid unintended ref deletion 18 November 2022, 23:43:11 UTC
ad90968 Merge branch 'tb/repack-expire-to' "git repack" learns to send cruft objects out of the way into packfiles outside the repository. * tb/repack-expire-to: builtin/repack.c: implement `--expire-to` for storing pruned objects builtin/repack.c: write cruft packs to arbitrary locations builtin/repack.c: pass "cruft_expiration" to `write_cruft_pack` builtin/repack.c: pass "out" to `prepare_pack_objects` 18 November 2022, 23:43:09 UTC
e53598a Merge branch 'ab/sha-makefile-doc' Makefile comments updates and reordering to clarify knobs used to choose SHA implementations. * ab/sha-makefile-doc: Makefile: discuss SHAttered in *_SHA{1,256} discussion Makefile: document default SHA-1 backend on OSX Makefile & test-tool: replace "DC_SHA1" variable with a "define" Makefile: document SHA-1 and SHA-256 default and selection order Makefile: document default SHA-256 backend Makefile: rephrase the discussion of *_SHA1 knobs Makefile: create and use sections for "define" flag listing Makefile: correct DC_SHA1 documentation INSTALL: remove discussion of SHA-1 backends Makefile: always (re)set DC_SHA1 on fallback 18 November 2022, 23:43:07 UTC
69c1d60 Merge branch 'ab/misc-hook-submodule-run-command' Various test updates. * ab/misc-hook-submodule-run-command: run-command tests: test stdout of run_command_parallel() submodule tests: reset "trace.out" between "grep" invocations hook tests: fix redirection logic error in 96e7225b310 18 November 2022, 23:43:04 UTC
7025f54 delta-islands: free island-related data after use On my use case involving 771 islands of Linux on kernel.org, this reduces memory usage by around 25MB. The bulk of that comes from free_remote_islands, since free_config_regexes only saves around 40k. This memory is saved early in the memory-intensive pack process, making it available for the remainder of the long process. Signed-off-by: Eric Wong <e@80x24.org> Co-authored-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 18 November 2022, 23:30:49 UTC
bcec678 receive-pack: only use visible refs for connectivity check When serving a push, git-receive-pack(1) needs to verify that the packfile sent by the client contains all objects that are required by the updated references. This connectivity check works by marking all preexisting references as uninteresting and using the new reference tips as starting point for a graph walk. Marking all preexisting references as uninteresting can be a problem when it comes to performance. Git forges tend to do internal bookkeeping to keep alive sets of objects for internal use or make them easy to find via certain references. These references are typically hidden away from the user so that they are neither advertised nor writeable. At GitLab, we have one particular repository that contains a total of 7 million references, of which 6.8 million are indeed internal references. With the current connectivity check we are forced to load all these references in order to mark them as uninteresting, and this alone takes around 15 seconds to compute. We can optimize this by only taking into account the set of visible refs when marking objects as uninteresting. This means that we may now walk more objects until we hit any object that is marked as uninteresting. But it is rather unlikely that clients send objects that make large parts of objects reachable that have previously only ever been hidden, whereas the common case is to push incremental changes that build on top of the visible object graph. This provides a huge boost to performance in the mentioned repository, where the vast majority of its refs hidden. Pushing a new commit into this repo with `transfer.hideRefs` set up to hide 6.8 million of 7 refs as it is configured in Gitaly leads to a 4.5-fold speedup: Benchmark 1: main Time (mean ± σ): 30.977 s ± 0.157 s [User: 30.226 s, System: 1.083 s] Range (min … max): 30.796 s … 31.071 s 3 runs Benchmark 2: pks-connectivity-check-hide-refs Time (mean ± σ): 6.799 s ± 0.063 s [User: 6.803 s, System: 0.354 s] Range (min … max): 6.729 s … 6.850 s 3 runs Summary 'pks-connectivity-check-hide-refs' ran 4.56 ± 0.05 times faster than 'main' As we mostly go through the same codepaths even in the case where there are no hidden refs at all compared to the code before there is no change in performance when no refs are hidden: Benchmark 1: main Time (mean ± σ): 48.188 s ± 0.432 s [User: 49.326 s, System: 5.009 s] Range (min … max): 47.706 s … 48.539 s 3 runs Benchmark 2: pks-connectivity-check-hide-refs Time (mean ± σ): 48.027 s ± 0.500 s [User: 48.934 s, System: 5.025 s] Range (min … max): 47.504 s … 48.500 s 3 runs Summary 'pks-connectivity-check-hide-refs' ran 1.00 ± 0.01 times faster than 'main' Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Taylor Blau <me@ttaylorr.com> 17 November 2022, 21:22:52 UTC
5ff36c9 rev-parse: add `--exclude-hidden=` option Add a new `--exclude-hidden=` option that is similar to the one we just added to git-rev-list(1). Given a section name `uploadpack` or `receive` as argument, it causes us to exclude all references that would be hidden by the respective `$section.hideRefs` configuration. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Taylor Blau <me@ttaylorr.com> 17 November 2022, 21:22:52 UTC
8c1bc2a revision: add new parameter to exclude hidden refs Users can optionally hide refs from remote users in git-upload-pack(1), git-receive-pack(1) and others via the `transfer.hideRefs`, but there is not an easy way to obtain the list of all visible or hidden refs right now. We'll require just that though for a performance improvement in our connectivity check. Add a new option `--exclude-hidden=` that excludes any hidden refs from the next pseudo-ref like `--all` or `--branches`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Taylor Blau <me@ttaylorr.com> 17 November 2022, 21:22:52 UTC
1e9f273 revision: introduce struct to handle exclusions The functions that handle exclusion of refs work on a single string list. We're about to add a second mechanism for excluding refs though, and it makes sense to reuse much of the same architecture for both kinds of exclusion. Introduce a new `struct ref_exclusions` that encapsulates all the logic related to excluding refs and move the `struct string_list` that holds all wildmatch patterns of excluded refs into it. Rename functions that operate on this struct to match its name. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Taylor Blau <me@ttaylorr.com> 17 November 2022, 21:22:52 UTC
05b9425 revision: move together exclusion-related functions Move together the definitions of functions that handle exclusions of refs so that related functionality sits in a single place, only. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Taylor Blau <me@ttaylorr.com> 17 November 2022, 21:22:51 UTC
9b67eb6 refs: get rid of global list of hidden refs We're about to add a new argument to git-rev-list(1) that allows it to add all references that are visible when taking `transfer.hideRefs` et al into account. This will require us to potentially parse multiple sets of hidden refs, which is not easily possible right now as there is only a single, global instance of the list of parsed hidden refs. Refactor `parse_hide_refs_config()` and `ref_is_hidden()` so that both take the list of hidden references as input and adjust callers to keep a local list, instead. This allows us to easily use multiple hidden-ref lists. Furthermore, it allows us to properly free this list before we exit. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Taylor Blau <me@ttaylorr.com> 17 November 2022, 21:22:51 UTC
5eeb9aa refs: fix memory leak when parsing hideRefs config When parsing the hideRefs configuration, we first duplicate the config value so that we can modify it. We then subsequently append it to the `hide_refs` string list, which is initialized with `strdup_strings` enabled. As a consequence we again reallocate the string, but never free the first duplicate and thus have a memory leak. While we never clean up the static `hide_refs` variable anyway, this is no excuse to make the leak worse by leaking every value twice. We are also about to change the way this variable will be handled so that we do indeed start to clean it up. So let's fix the memory leak by using the `string_list_append_nodup()` so that we pass ownership of the allocated string to `hide_refs`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Taylor Blau <me@ttaylorr.com> 17 November 2022, 21:22:51 UTC
3c9b01f notes: avoid empty line in template When `git notes` prepares the template it adds an empty newline between the comment header and the content: > > # > # Write/edit the notes for the following object: > > # commit 0f3c55d4c2b7864bffb2d92278eff08d0b2e083f > # etc This is wrong structurally because that newline is part of the comment, too, and thus should be commented. Also, it throws off some positioning strategies of editors and plugins, and it differs from how we do commit templates. Change this to follow the standard set by `git commit`: > > # > # Write/edit the notes for the following object: > # > # commit 0f3c55d4c2b7864bffb2d92278eff08d0b2e083f > Tests pass unchanged after this code change. Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Taylor Blau <me@ttaylorr.com> 16 November 2022, 19:57:32 UTC
23fb328 t7610: use "file:///dev/null", not "/dev/null", fixes MinGW On MinGW the "/dev/null" is translated to "nul" on command-lines, even though as in this case it'll never end up referring to an actual file. So on Windows the fix for the previous "example.com" timeout issue in 8354cf752ec (t7610: fix flaky timeout issue, don't clone from example.com, 2022-11-05) would yield: fatal: repo URL: 'nul' must be absolute or begin with ./|../ Let's evade this yet again by prefixing this with "file://", which makes this pass in the Windows CI. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 16 November 2022, 01:05:02 UTC
03744bb builtin/gc.c: fix use-after-free in maintenance_unregister() While trying to fix a move based on an uninitialized value (along with a declaration after the first statement), be0fd57228 (maintenance --unregister: fix uninit'd data use & -Wdeclaration-after-statement, 2022-11-15) unintentionally introduced a use-after-free. The problem arises when `maintenance_unregister()` sees a non-NULL `config_file` string and thus tries to call git_configset_get_value_multi() to lookup the corresponding values. We store the result off, and then call git_configset_clear(), which frees the pointer that we just stored. We then try to read that now-freed pointer a few lines below, and there we have our use-after-free: $ ./t7900-maintenance.sh -vxi --run=23 --valgrind [...] + git maintenance unregister --config-file ./other ==3048727== Invalid read of size 8 ==3048727== at 0x1869CA: maintenance_unregister (gc.c:1590) ==3048727== by 0x188F42: cmd_maintenance (gc.c:2651) ==3048727== by 0x128C62: run_builtin (git.c:466) ==3048727== by 0x12907E: handle_builtin (git.c:721) ==3048727== by 0x1292EC: run_argv (git.c:788) ==3048727== by 0x12988E: cmd_main (git.c:926) ==3048727== by 0x21ED39: main (common-main.c:57) ==3048727== Address 0x4b38bc8 is 24 bytes inside a block of size 64 free'd ==3048727== at 0x484617B: free (vg_replace_malloc.c:872) ==3048727== by 0x2D207E: free_individual_entries (hashmap.c:188) ==3048727== by 0x2D2153: hashmap_clear_ (hashmap.c:207) ==3048727== by 0x270B5C: git_configset_clear (config.c:2375) ==3048727== by 0x1869AC: maintenance_unregister (gc.c:1585) ==3048727== by 0x188F42: cmd_maintenance (gc.c:2651) ==3048727== by 0x128C62: run_builtin (git.c:466) ==3048727== by 0x12907E: handle_builtin (git.c:721) ==3048727== by 0x1292EC: run_argv (git.c:788) ==3048727== by 0x12988E: cmd_main (git.c:926) ==3048727== by 0x21ED39: main (common-main.c:57) [...] Resolve this via a partial-revert of be0fd57228. The config_set struct now gets a zero initialization, which makes free()-ing it a noop even without calling git_configset_init(). When we do initialize it to a non-zero value, it is only free()'d after our last read of `list`. Signed-off-by: Taylor Blau <me@ttaylorr.com> 15 November 2022, 18:56:11 UTC
be0fd57 maintenance --unregister: fix uninit'd data use & -Wdeclaration-after-statement Since (maintenance: add option to register in a specific config, 2022-11-09) we've been unable to build with "DEVELOPER=1" without "DEVOPTS=no-error", as the added code triggers a "-Wdeclaration-after-statement" warning. And worse than that, the data handed to git_configset_clear() is uninitialized, as can be spotted with e.g.: ./t7900-maintenance.sh -vixd --run=23 --valgrind [...] + git maintenance unregister --force Conditional jump or move depends on uninitialised value(s) at 0x6B5F1E: git_configset_clear (config.c:2367) by 0x4BA64E: maintenance_unregister (gc.c:1619) by 0x4BD278: cmd_maintenance (gc.c:2650) by 0x409905: run_builtin (git.c:466) by 0x40A21C: handle_builtin (git.c:721) by 0x40A58E: run_argv (git.c:788) by 0x40AF68: cmd_main (git.c:926) by 0x5D39FE: main (common-main.c:57) Uninitialised value was created by a stack allocation at 0x4BA22C: maintenance_unregister (gc.c:1557) Let's fix both of these issues, and also move the scope of the variable to the "if" statement it's used in, to make it obvious where it's used. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 15 November 2022, 17:31:53 UTC
1f80129 maintenance: add option to register in a specific config maintenance register currently records the maintenance repo exclusively within the user's global configuration, but other configuration files may be relevant when running maintenance if they are included from the global config. This option allows the user to choose where maintenance repos are recorded. Signed-off-by: Ronan Pigott <ronan@rjp.ie> Signed-off-by: Taylor Blau <me@ttaylorr.com> 15 November 2022, 03:39:25 UTC
13d5bbd for-each-repo: interpolate repo path arguments This is a quality of life change for git-maintenance, so repos can be recorded with the tilde syntax. The register subcommand will not record repos in this format by default. Signed-off-by: Ronan Pigott <ronan@rjp.ie> Signed-off-by: Taylor Blau <me@ttaylorr.com> 15 November 2022, 03:39:25 UTC
eea7033 The twelfth batch Signed-off-by: Taylor Blau <me@ttaylorr.com> 15 November 2022, 00:56:07 UTC
3c5d0ce Merge branch 'vh/my-first-contribution-typo' Documentation fix. * vh/my-first-contribution-typo: Documentation: fix typo 15 November 2022, 00:53:55 UTC
859899d Merge branch 'ks/partialclone-casing' Documentation fix. * ks/partialclone-casing: repository-version.txt: partialClone casing change 15 November 2022, 00:53:43 UTC
dc8be39 Merge branch 'mh/password-can-be-pat' Documentation update to git-credential(1). * mh/password-can-be-pat: Documentation/gitcredentials.txt: mention password alternatives 15 November 2022, 00:53:42 UTC
69eb1be Merge branch 'js/ci-set-output' Update the actions/github-script dependency in CI to avoid a deprecation warning. * js/ci-set-output: ci: use a newer `github-script` version 15 November 2022, 00:53:38 UTC
311bf13 Merge branch 'ab/rev-info-init' Progress on being able to initialize a rev_info struct with a macro. * ab/rev-info-init: revisions API: extend the nascent REV_INFO_INIT macro 15 November 2022, 00:53:37 UTC
d0c3853 Merge branch 'al/trace2-clearing-skip-worktree' Add trace2 counters to the region to clear skip worktree bits in a sparse checkout. * al/trace2-clearing-skip-worktree: index: raise a bug if the index is materialised more than once index: add trace2 region for clear skip worktree 15 November 2022, 00:53:34 UTC
561f394 Merge branch 'do/modernize-t7001' Modernize test script to avoid "test -f" and friends. * do/modernize-t7001: t7001-mv.sh: modernizing test script using functions 15 November 2022, 00:53:31 UTC
dabb9d8 Docs: describe how a credential-generating helper works Previously the docs only described storage helpers. A concrete example: Git Credential Manager can generate credentials for GitHub and GitLab via OAuth. https://github.com/GitCredentialManager/git-credential-manager Signed-off-by: M Hickford <mirth.hickford@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 14 November 2022, 23:18:59 UTC
c5353c4 Documentation: fix typo Signed-off-by: Vlad-Stefan Harbuz <vlad@vladh.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> 14 November 2022, 23:14:58 UTC
b637a41 http: redact curl h2h3 headers in info With GIT_TRACE_CURL=1 or GIT_CURL_VERBOSE=1, sensitive headers like "Authorization" and "Cookie" get redacted. However, since [1], curl's h2h3 module (invoked when using HTTP/2) also prints headers in its "info", which don't get redacted. For example, echo 'github.com TRUE / FALSE 1698960413304 o foo=bar' >cookiefile && GIT_TRACE_CURL=1 GIT_TRACE_CURL_NO_DATA=1 git \ -c 'http.cookiefile=cookiefile' \ -c 'http.version=' \ ls-remote https://github.com/git/git refs/heads/main 2>output && grep 'cookie' output produces output like: 23:04:16.920495 http.c:678 == Info: h2h3 [cookie: o=foo=bar] 23:04:16.920562 http.c:637 => Send header: cookie: o=<redacted> Teach http.c to check for h2h3 headers in info and redact them using the existing header redaction logic. This fixes the broken redaction logic that we noted in the previous commit, so mark the redaction tests as passing under HTTP2. [1] https://github.com/curl/curl/commit/f8c3724aa90472c0e617ddbbc420aa199971eb77 Helped-by: Jeff King <peff@peff.net> Signed-off-by: Glen Choo <chooglen@google.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 14 November 2022, 22:42:46 UTC
73c49a4 t: run t5551 tests with both HTTP and HTTP/2 We have occasionally seen bugs that affect Git running only against an HTTP/2 web server, not an HTTP one. For instance, b66c77a64e (http: match headers case-insensitively when redacting, 2021-09-22). But since we have no test coverage using HTTP/2, we only uncover these bugs in the wild. That commit gives a recipe for converting our Apache setup to support HTTP/2, but: - it's not necessarily portable - we don't want to just test HTTP/2; we really want to do a variety of basic tests for _both_ protocols This patch handles both problems by running a duplicate of t5551 (labeled as t5559 here) with an alternate-universe setup that enables HTTP/2. So we'll continue to run t5551 as before, but run the same battery of tests again with HTTP/2. If HTTP/2 isn't supported on a given platform, then t5559 should bail during the webserver setup, and gracefully skip all tests (unless GIT_TEST_HTTPD has been changed from "auto" to "yes", where the point is to complain when webserver setup fails). In theory other http-related test scripts could benefit from the same duplication, but doing t5551 should give us a reasonable check of basic functionality, and would have caught both bugs we've seen in the wild with HTTP/2. A few notes on the implementation: - a script enables the server side config by calling enable_http2 before starting the webserver. This avoids even trying to load any HTTP/2 config for t5551 (which is what lets it keep working with regular HTTP even on systems that don't support it). This also sets a prereq which can be used by individual tests. - As discussed in b66c77a64e, the http2 module isn't compatible with the "prefork" mpm, so we need to pick something else. I chose "event" here, which works on my Debian system, but it's possible there are platforms which would prefer something else. We can adjust that later if somebody finds such a platform. - The test "large fetch-pack requests can be sent using chunked encoding" makes sure we use a chunked transfer-encoding by looking for that header in the trace. But since HTTP/2 has its own streaming mechanisms, we won't find such a header. We could skip the test entirely by marking it with !HTTP2. But there's some value in making sure that the fetch itself succeeded. So instead, we'll confirm that either we're using HTTP2 _or_ we saw the expected chunked header. - the redaction tests fail under HTTP/2 with recent versions of curl. This is a bug! I've marked them with !HTTP2 here to skip them under t5559 for the moment. Using test_expect_failure would be more appropriate, but would require a bunch of boilerplate. Since we'll be fixing them momentarily, let's just skip them for now to keep the test suite bisectable, and we can re-enable them in the commit that fixes the bug. - one alternative layout would be to push most of t5551 into a lib-t5551.sh script, then source it from both t5551 and t5559. Keeping t5551 intact seemed a little simpler, as its one less level of indirection for people fixing bugs/regressions in the non-HTTP/2 tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> 14 November 2022, 22:42:46 UTC
e62f779 Doc: document push.recurseSubmodules=only Git learned pushing submodules without pushing the superproject by the user specifying --recurse-submodules=only through 6c656c3fe4 ("submodules: add RECURSE_SUBMODULES_ONLY value", 2016-12-20) and 225e8bf778 ("push: add option to push only submodules", 2016-12-20). For users who use this feature regularly, it is desirable to have an equivalent configuration. It turns out that such a configuration (push.recurseSubmodules=only) is already supported, even though it is neither documented nor mentioned in the commit messages, due to the way the --recurse-submodules=only feature was implemented (a function used to parse --recurse-submodules was updated to support "only", but that same function is used to parse push.recurseSubmodules too). What is left is to document it and test it, which is what this commit does. There is a possible point of confusion when recursing into a submodule that itself has the push.recurseSubmodules=only configuration, because if a repository has only its submodules pushed and not itself, its superproject can never be pushed. Therefore, treat such configurations as being "on-demand", and print a warning message. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 14 November 2022, 21:55:50 UTC
7fd54b6 docs: clarify that credential discards unrecognised attributes It was previously unclear how unrecognised attributes are handled. Signed-off-by: M Hickford <mirth.hickford@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 13 November 2022, 04:57:34 UTC
a90085b tests(scalar): tighten the stale `scalar.repo` test some As pointed out by Stolee, the previous incarnation of this test case was not stringent enough: we want to verify that _only_ the stale entries are removed (previously, the test case would have succeeded even if all entries had been removed). Let's rectify this and verify that the other entries are left intact. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 22:24:36 UTC
29c550f repository-version.txt: partialClone casing change Remotes are considered "promisor" if extensions.partialClone and some other configuration variables are set. The casing for this in Documentation/technical/repository-version.txt is not proper and may cause confusion. This change corrects this casing. Signed-off-by: Kousik Sanagavarapu <five231003@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 22:23:12 UTC
0d12792 Makefile: don't create a ".build/.build/" for cocci, fix output Fix a couple of issues in the recently merged 0f3c55d4c2b (Merge branch 'ab/coccicheck-incremental' into next, 2022-11-08): In copying over the "contrib/coccinelle/" rules to ".build/contrib/coccinelle/" we inadvertently ended up with a ".build/.build/contrib/coccinelle/" as well. We'd generate the per-file patches in the former, and keep the rule and overall result in the latter. E.g. running: make contrib/coccinelle/free.cocci.patch COCCI_SOURCES="attr.c grep.c" Would, per "tree -a .build" yield the following result: .build ├── .build │   └── contrib │   └── coccinelle │   └── free.cocci.patch │   ├── attr.c │   ├── attr.c.log │   ├── grep.c │   └── grep.c.log └── contrib └── coccinelle ├── FOUND_H_SOURCES ├── free.cocci └── free.cocci.patch Now we'll instead generate all of our files in ".build/contrib/coccinelle/". Fixing this required renaming the directory where we keep our per-file patches, as we'd otherwise conflict with the result. Now the per-file patch directory is named e.g. "free.cocci.d". And the end result will now be: .build └── contrib └── coccinelle ├── FOUND_H_SOURCES ├── free.cocci ├── free.cocci.d │   ├── attr.c.patch │   ├── attr.c.patch.log │   ├── grep.c.patch │   └── grep.c.patch.log └── free.cocci.patch The per-file patches now have a ".patch" file suffix, which fixes another issue reported against 0f3c55d4c2b: The summary output was confusing. Before for the "make" command above we'd emit: [...] MKDIR -p .build/contrib/coccinelle CP contrib/coccinelle/free.cocci .build/contrib/coccinelle/free.cocci GEN .build/contrib/coccinelle/FOUND_H_SOURCES MKDIR -p .build/.build/contrib/coccinelle/free.cocci.patch SPATCH .build/.build/contrib/coccinelle/free.cocci.patch/grep.c SPATCH .build/.build/contrib/coccinelle/free.cocci.patch/attr.c SPATCH CAT $^ >.build/contrib/coccinelle/free.cocci.patch CP .build/contrib/coccinelle/free.cocci.patch contrib/coccinelle/free.cocci.patch But now we'll instead emit (identical output at the start omitted): [...] MKDIR -p .build/contrib/coccinelle/free.cocci.d SPATCH grep.c >.build/contrib/coccinelle/free.cocci.d/grep.c.patch SPATCH attr.c >.build/contrib/coccinelle/free.cocci.d/attr.c.patch SPATCH CAT .build/contrib/coccinelle/free.cocci.d/**.patch >.build/contrib/coccinelle/free.cocci.patch CP .build/contrib/coccinelle/free.cocci.patch contrib/coccinelle/free.cocci.patch I.e. we have an "SPATCH" line that makes it clear that we're running against the "{attr,grep}.c" file. The "SPATCH CAT" is then altered to correspond to it, showing that we're concatenating the "free.cocci.d/**.patch" files into one generated "free.cocci.patch" at the end. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 22:21:45 UTC
e9011b6 bisect--helper: parse subcommand with OPT_SUBCOMMAND As of it is, we're parsing subcommand with OPT_CMDMODE, which will continue to parse more options even if the command has been found. When we're running "git bisect run" with a command that expecting a "--log" or "--no-log" arguments, or one of those "--bisect-..." arguments, bisect--helper may mistakenly think those options are bisect--helper's option. We may fix those problems by passing "--" when calling from git-bisect.sh, and skip that "--" in bisect--helper. However, it may interfere with user's "--". Let's parse subcommand with OPT_SUBCOMMAND since that API was born for this specific use-case. Reported-by: Lukáš Doktor <ldoktor@redhat.com> Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 22:04:57 UTC
464ce0a bisect--helper: move all subcommands into their own functions In a later change, we will use OPT_SUBCOMMAND to parse sub-commands to avoid consuming non-option opts. Since OPT_SUBCOMMAND needs a function pointer to operate, let's move it now. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 22:04:54 UTC
58786d7 bisect--helper: remove unused options 'git-bisect.sh' used to have a 'bisect_next_check' to check if we have both good/bad, old/new terms set or not. In commit 129a6cf344 (bisect--helper: `bisect_next_check` shell function in C, 2019-01-02), a subcommand for bisect--helper was introduced to port the check to C. Since d1bbbe45df (bisect--helper: reimplement `bisect_run` shell function in C, 2021-09-13), all users of 'bisect_next_check' was re-implemented in C, this subcommand was no longer used but we forgot to remove '--bisect-next-check'. 'git-bisect.sh' also used to have a 'bisect_write' function, whose third positional parameter was a "nolog" flag. This flag was only used when 'bisect_start' invoked 'bisect_write' to write the starting good and bad revisions. Then 0f30233a11 (bisect--helper: `bisect_write` shell function in C, 2019-01-02) ported it to C as a command mode of 'bisect--helper', which (incorrectly) added the '--no-log' option, and convert the only place ('bisect_start') that call 'bisect_write' with 'nolog' to 'git bisect--helper --bisect-write' with 'nolog' instead of '--no-log', since 'bisect--helper' has command modes not subcommands, all other command modes see and handle that option as well. This bogus state didn't last long, however, because in the same patch series 06f5608c14 (bisect--helper: `bisect_start` shell function partially in C, 2019-01-02) the C reimplementation of bisect_start() started calling the bisect_write() C function, this time with the right 'nolog' function parameter. From then on there was no need for the '--no-log' option in 'bisect--helper'. Eventually all bisect subcommands were ported to C as 'bisect--helper' command modes, each calling the bisect_write() C function instead, but when the '--bisect-write' command mode was removed in 68efed8c8a (bisect--helper: retire `--bisect-write` subcommand, 2021-02-03) it forgot to remove that '--no-log' option. '--no-log' option had never been used and it's unused now. Let's remove --bisect-next-check and --no-log from option parsing. Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 22:04:52 UTC
48d69d8 chainlint: prefix annotated test definition with line numbers When chainlint detects problems in a test, it prints out the name of the test script, the name of the problematic test, and a copy of the test definition with "?!FOO?!" annotations inserted at the locations where problems were detected. Taken together this information is sufficient for the test author to identify the problematic code in the original test definition. However, in a lengthy script or a lengthy test definition, the author may still end up using the editor's search feature to home in on the exact problem location. To further assist the test author, display line numbers along with the annotated test definition, thus allowing the author to jump directly to each problematic line. Suggested-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 21:56:21 UTC
bf42f0a chainlint: latch line numbers at which each token starts and ends When chainlint detects problems in a test, it prints out the name of the test script, the name of the problematic test, and a copy of the test definition with "?!FOO?!" annotations inserted at the locations where problems were detected. Taken together this information is sufficient for the test author to identify the problematic code in the original test definition. However, in a lengthy script or a lengthy test definition, the author may still end up using the editor's search feature to home in on the exact problem location. To further assist the test author, an upcoming change will display line numbers along with the annotated test definition, thus allowing the author to jump directly to each problematic line. As preparation, upgrade Lexer to latch the line numbers at which each token starts and ends, and return that information with the token itself. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 21:56:21 UTC
5451877 chainlint: sidestep impoverished macOS "terminfo" Although the macOS Terminal.app is "xterm"-compatible, its corresponding "terminfo" entries -- such as "xterm", "xterm-256color", and "xterm-new"[1] -- neglect to mention capabilities which Terminal.app actually supports (such as "dim text"). This oversight on Apple's part ends up penalizing users of "good citizen" console programs which consult "terminfo" to tailor their output based upon reported terminal capabilities (as opposed to programs which assume that the terminal supports ANSI codes). The same problem is present in other Apple "terminfo" entries, such as "nsterm"[2], with which macOS Terminal.app may be configured. Sidestep this Apple problem by imbuing get_colors() with specific knowledge of capabilities common to "xterm" and "nsterm", rather than trusting "terminfo" to report them correctly. Although hard-coding such knowledge is ugly, "xterm" support is nearly ubiquitous these days, and Git itself sets precedence by assuming support for ANSI color codes. For other terminal types, fall back to querying "terminfo" via `tput` as usual. FOOTNOTES [1] iTerm2 FAQ suggests "xterm-new": https://iterm2.com/faq.html [2] Neovim documentation recommends terminal type "nsterm" with Terminal.app: https://neovim.io/doc/user/term.html#terminfo Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 21:56:21 UTC
688d82f sequencer: tighten label lookups The `label` command creates a ref refs/rewritten/<label> that the `reset` and `merge` commands resolve by calling lookup_label(). That uses lookup_commit_reference_by_name() to look up the label ref. As lookup_commit_reference_by_name() uses the dwim rules when looking up the label it will look for a branch named refs/heads/refs/rewritten/<label> and return that instead of an error if the branch exists and the label does not. Fix this by using read_ref() followed by lookup_commit_object() when looking up labels. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 04:36:24 UTC
82766b2 sequencer: unify label lookup The arguments to the `reset` and `merge` commands may be a label created with a `label` command or an arbitrary commit name. The `merge` command uses the lookup_label() function to lookup its arguments but `reset` has a slightly different version of that function in do_reset(). Reduce this code duplication by calling lookup_label() from do_reset() as well. This change improves the behavior of `reset` when the argument is a tree. Previously `reset` would accept a tree only for the rebase to fail with update_ref failed for ref 'HEAD': cannot update ref 'HEAD': trying to write non-commit object da5497437fd67ca928333aab79c4b4b55036ea66 to branch 'HEAD' Using lookup_label() means do_reset() will now error out straight away if its argument is not a commit. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 04:36:24 UTC
652bd02 rebase: use 'skip_cache_tree_update' option Enable the 'skip_cache_tree_update' option in both 'do_reset()' ('sequencer.c') and 'reset_head()' ('reset.c'). Both of these callers invoke 'prime_cache_tree()' after 'unpack_trees()', so we can remove an unnecessary cache tree rebuild by skipping 'cache_tree_update()'. When testing with 'p3400-rebase.sh' and 'p3404-rebase-interactive.sh', the performance change of this update was negligible, likely due to the operation being dominated by more expensive operations (like checking out trees). However, since the change doesn't harm performance, it's worth keeping this 'unpack_trees()' usage consistent with others that subsequently invoke 'prime_cache_tree()'. Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 02:49:34 UTC
dc5d40f read-tree: use 'skip_cache_tree_update' option When running 'read-tree' with a single tree and no prefix, 'prime_cache_tree()' is called after the tree is unpacked. In that situation, skip a redundant call to 'cache_tree_update()' in 'unpack_trees()' by enabling the 'skip_cache_tree_update' unpack option. Removing the redundant cache tree update provides a substantial performance improvement to 'git read-tree <tree-ish>', as shown by a test added to 'p0006-read-tree-checkout.sh': Test before after ---------------------------------------------------------------------- read-tree br_ballast_plus_1 3.94(1.80+1.57) 3.00(1.14+1.28) -23.9% Note that the 'read-tree' in 't1022-read-tree-partial-clone.sh' is updated to read two trees, rather than one. The test was first introduced in d3da223f221 (cache-tree: prefetch in partial clone read-tree, 2021-07-23) to exercise the 'cache_tree_update()' code path, as used in 'git merge'. Since this patch drops the call to 'cache_tree_update()' in single-tree 'git read-tree', change the test to use the two-tree variant so that 'cache_tree_update()' is called as intended. Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 02:49:34 UTC
0e47bca reset: use 'skip_cache_tree_update' option Enable the 'skip_cache_tree_update' option in the variants that call 'prime_cache_tree()' after 'unpack_trees()' (specifically, 'git reset --mixed' and 'git reset --hard'). This avoids redundantly rebuilding the cache tree in both 'cache_tree_update()' at the end of 'unpack_trees()' and in 'prime_cache_tree()', resulting in a small (but consistent) performance improvement. From the newly-added 'p7102-reset.sh' test: Test before after -------------------------------------------------------------------- 7102.1: reset --hard (...) 2.11(0.40+1.54) 1.97(0.38+1.47) -6.6% Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 02:49:34 UTC
68fcd48 unpack-trees: add 'skip_cache_tree_update' option Add (disabled by default) option to skip the 'cache_tree_update()' at the end of 'unpack_trees()'. In many cases, this cache tree update is redundant because the caller of 'unpack_trees()' immediately follows it with 'prime_cache_tree()', rebuilding the entire cache tree from scratch. While these operations aren't the most expensive part of operations like 'git reset', the duplicate calls still create a minor unnecessary slowdown. Introduce an option for callers to skip the 'cache_tree_update()' in 'unpack_trees()' if it is redundant (that is, if 'prime_cache_tree()' is called afterwards). At the moment, no 'unpack_trees()' callers use the new option; they will be updated in subsequent patches. Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 02:49:34 UTC
94fcf0e cache-tree: add perf test comparing update and prime Add a performance test comparing the execution times of 'prime_cache_tree()' and 'cache_tree_update(_, WRITE_TREE_SILENT | WRITE_TREE_REPAIR)'. The goal of comparing these two is to identify which is the faster method for rebuilding an invalid cache tree, ultimately to remove one when both are (reundantly) called in immediate succession. Both methods are fast, so the new tests in 'p0090-cache-tree.sh' must call each tested function multiple times to ensure the reported times (to 0.01s resolution) convey the differences between them. The tests compare the timing of a 'test-tool cache-tree' run as a no-op (to capture a baseline for the overhead associated with running the tool), 'cache_tree_update()', and 'prime_cache_tree()' on four scenarios: - A completely valid cache tree - A cache tree with 2 invalid paths - A cache tree with 50 invalid paths - A completely empty cache tree Example results: Test this tree ----------------------------------------------------------- 0090.2: no-op, clean 1.27(0.48+0.52) 0090.3: prime_cache_tree, clean 2.02(0.83+0.85) 0090.4: cache_tree_update, clean 1.30(0.49+0.54) 0090.5: no-op, invalidate 2 1.29(0.48+0.54) 0090.6: prime_cache_tree, invalidate 2 1.98(0.81+0.83) 0090.7: cache_tree_update, invalidate 2 2.12(0.94+0.86) 0090.8: no-op, invalidate 50 1.32(0.50+0.55) 0090.9: prime_cache_tree, invalidate 50 2.10(0.86+0.89) 0090.10: cache_tree_update, invalidate 50 2.35(1.14+0.90) 0090.11: no-op, empty 1.33(0.50+0.54) 0090.12: prime_cache_tree, empty 2.04(0.84+0.87) 0090.13: cache_tree_update, empty 2.51(1.27+0.92) These timings show that, while 'cache_tree_update()' is faster when the cache tree is completely valid, it is equal to or slower than 'prime_cache_tree()' when there are any invalid paths. Since the redundant calls are mostly in scenarios where the cache tree will be at least partially invalid (e.g., 'git reset --hard'), 'prime_cache_tree()' will likely perform better than 'cache_tree_update()' in typical cases. Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Victoria Dye <vdye@github.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 02:49:33 UTC
eb20e63 branch: gracefully handle '-d' on orphan HEAD When deleting a branch, "git branch -d" has a safety check that ensures the branch is merged to its upstream (if any), or to HEAD. To do that, naturally we try to resolve HEAD to a commit object. If we're on an orphan branch (i.e., HEAD points to a branch that does not yet exist), that will fail, and we'll bail with an error: $ git branch -d to-delete fatal: Couldn't look up commit object for HEAD This usually isn't that big of a deal. The deletion would fail anyway, since the branch isn't merged to HEAD, and you'd need to use "-D" (or "-f"). And doing so skips the HEAD resolution, courtesy of 67affd5173 (git-branch -D: make it work even when on a yet-to-be-born branch, 2006-11-24). But there are still two problems: 1. The error message isn't very helpful. We should give the usual "not fully merged" message, which points the user at "branch -D". That was a problem even back in 67affd5173. 2. Even without a HEAD, these days it's still possible for the deletion to succeed. After 67affd5173, commit 99c419c915 (branch -d: base the "already-merged" safety on the branch it merges with, 2009-12-29) made it OK to delete a branch if it is merged to its upstream. We can fix both by removing the die() in delete_branches() completely, leaving head_rev NULL in this case. It's tempting to stop there, as it appears at first glance that the rest of the code does the right thing with a NULL. But sadly, it's not quite true. We end up feeding the NULL to repo_is_descendant_of(). In the traditional code path there, we call repo_in_merge_bases_many(). It feeds the NULL to repo_parse_commit(), which is smart enough to return an error, and we immediately return "no, it's not a descendant". But there's an alternate code path: if we have a commit graph with generation numbers, we end up in can_all_from_reach(), which does eventually try to set a flag on the NULL commit and segfaults. So instead, we'll teach the local branch_merged() helper to treat a NULL as "not merged". This would be a little more elegant in in_merge_bases() itself, but that function is called in a lot of places, and it's not clear that quietly returning "not merged" is the right thing everywhere (I'd expect in many cases, feeding a NULL is a sign of a bug). There are four tests here: a. The first one confirms that deletion succeeds with an orphaned HEAD when the branch is merged to its upstream. This is case (2) above. b. Same, but with commit graphs enabled. Even if it is merged to upstream, we still check head_rev so that we can say "deleting because it's merged to upstream, even though it's not merged to HEAD". Without the second hunk in branch_merged(), this test would segfault in can_all_from_reach(). c. The third one confirms that we correctly say "not merged to HEAD" when we can't resolve HEAD, and reject the deletion. d. Same, but with commit graphs enabled. Without the first hunk in branch_merged(), this one would segfault. Reported-by: Martin von Zweigbergk <martinvonz@google.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> 11 November 2022, 02:42:45 UTC
f13c3f2 Documentation: increase example cache timeout to 1 hour Previously, the example *decreased* the cache timeout compared to the default, making it less user friendly. Instead, nudge users to make cache more usable. Many users choose store over cache. https://lore.kernel.org/git/CAGJzqskRYN49SeS8kSEN5-vbB_Jt1QvAV9QhS6zNuKh0u8wxPQ@mail.gmail.com/ The default timeout remains 15 minutes. A stronger nudge would be to increase that. Signed-off-by: M Hickford <mirth.hickford@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 10 November 2022, 02:28:53 UTC
0e34efb rebase: stop exporting GIT_REFLOG_ACTION Now that struct replay_opts has a reflog_action member we no longer need to export GIT_REFLOG_ACTION when starting a rebase. If the user has set GIT_REFLOG_ACTION then we use it when initializing reflog_action. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 09 November 2022, 23:15:54 UTC
d188a60 sequencer: stop exporting GIT_REFLOG_ACTION Each time it picks a commit the sequencer copies the GIT_REFLOG_ACITON environment variable so it can temporarily change it and then restore the previous value. This results in code that is hard to follow and also leaks memory because (i) we fail to free the copy when we've finished with it and (ii) each call to setenv() leaks the previous value. Instead pass the reflog action around in a variable and use it to set GIT_REFLOG_ACTION in the child environment when running "git commit". Within the sequencer GIT_REFLOG_ACTION is no longer set and is only read by sequencer_reflog_action(). It is still set by rebase before calling the sequencer, that will be addressed in the next commit. cherry-pick and revert are unaffected as they do not set GIT_REFLOG_ACTION before calling the sequencer. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 09 November 2022, 23:15:43 UTC
8354cf7 t7610: fix flaky timeout issue, don't clone from example.com When t7610-mergetool.sh runs without failures the git://example.com submodule URLs will never be used. That's because we "git submodule add" it, but then manually populate them so that subsequent "git submodule update -N" won't attempt to clone it, only update it without fetching. But if we fail in an earlier test it'll have the knock-on effect of having later tests hang on that "git submodule update -N" as we attempt to clone this repository from example.com. This can be reproduced on "master" by running the test with SANITIZE=leak without "--immediate". With "GIT_TEST_PASSING_SANITIZE_LEAK=true" (which the linux-leaks job uses) we'll skip the test entirely. So we'll only run into this when running it manually, or with the "GIT_TEST_PASSING_SANITIZE_LEAK=check" mode. That's not because the failure has anything to do with leak detection per-se. It just so happens that we have a leak that'll fail before we've managed to fully set these up, and therefore "git submodule update -N" ends up spawning "git clone". Let's instead continue lying about the origin of this submodule by providing a URL for it that doesn't work, but now one that *really* doesn't work: /dev/null. If the test is passing we won't ever use this, and if we have knock-on failures we'll fail early, instead of waiting for a timeout. The behavior of "-N" here might be surprising to some, since it's explained as "[if you use -N we] don’t fetch new objects from the remote site". But (perhaps counter-intuitively) it's only talking about if it needs to do so via "git fetch". In this case we'll end up spawning a "git clone", as we have no submodule set up. See ff7f089ed10 (mergetool: Teach about submodules, 2011-04-13) for the commit that implemented these "example.com" tests. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 09 November 2022, 22:29:31 UTC
3a79a80 Merge branch 'es/chainlint-output' into es/chainlint-lineno * es/chainlint-output: chainlint: annotate original test definition rather than token stream chainlint: latch start/end position of each token chainlint: tighten accuracy when consuming input stream chainlint: add explanatory comments 09 November 2022, 21:41:35 UTC
319605f The eleventh batch Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 22:18:48 UTC
be4ac3b Merge branch 'rs/no-more-run-command-v' Simplify the run-command API. * rs/no-more-run-command-v: replace and remove run_command_v_opt() replace and remove run_command_v_opt_cd_env_tr2() replace and remove run_command_v_opt_tr2() replace and remove run_command_v_opt_cd_env() use child_process members "args" and "env" directly use child_process member "args" instead of string array variable sequencer: simplify building argument list in do_exec() bisect--helper: factor out do_bisect_run() bisect: simplify building "checkout" argument list am: simplify building "show" argument list run-command: fix return value comment merge: remove always-the-same "verbose" arguments 08 November 2022, 22:15:12 UTC
3e9303d Merge branch 'rs/archive-filter-error-once' "git archive" mistakenly complained twice about a missing executable, which has been corrected. * rs/archive-filter-error-once: archive-tar: report filter start error only once 08 November 2022, 22:15:09 UTC
ec9a46a Merge branch 'ma/drop-redundant-diagnostic' A redundant diagnostic message is dropped from test_path_is_missing(). * ma/drop-redundant-diagnostic: test-lib-functions: drop redundant diagnostic print 08 November 2022, 22:15:06 UTC
d957761 Merge branch 'vb/ls-files-docfix' Docfix. * vb/ls-files-docfix: ls-files: fix --ignored and --killed flags in synopsis 08 November 2022, 22:14:53 UTC
15df841 Merge branch 'jk/ref-filter-parsing-bugs' Various tests exercising the transfer.credentialsInUrl configuration are taught to avoid making requests which require resolving localhost to reduce CI-flakiness. * jk/ref-filter-parsing-bugs: ref-filter: fix parsing of signatures with CRLF and no body ref-filter: fix parsing of signatures without blank lines 08 November 2022, 22:14:52 UTC
4b6302c Merge branch 'po/glossary-around-traversal' The glossary entries for "commit-graph file" and "reachability bitmap" have been added. * po/glossary-around-traversal: glossary: add reachability bitmap description glossary: add "commit graph" description doc: use 'object database' not ODB or abbreviation doc: use "commit-graph" hyphenation consistently 08 November 2022, 22:14:51 UTC
06e7696 Merge branch 'jc/set-gid-bit-less-aggressively' The adjust_shared_perm() helper function learned to refrain from setting the "g+s" bit on directories when it is not necessary. * jc/set-gid-bit-less-aggressively: adjust_shared_perm(): leave g+s alone when the group does not matter 08 November 2022, 22:14:49 UTC
bdd42e3 Merge branch 'es/mark-gc-cruft-as-experimental' Enable gc.cruftpacks by default for those who opt into feature.experimental setting. * es/mark-gc-cruft-as-experimental: config: let feature.experimental imply gc.cruftPacks=true gc: add tests for --cruft and friends 08 November 2022, 22:14:48 UTC
098b1d0 Merge branch 'tb/howto-using-redo-script' Doc update. * tb/howto-using-redo-script: Documentation/howto/maintain-git.txt: fix Meta/redo-jch.sh invocation 08 November 2022, 22:14:45 UTC
54e95b4 Documentation/gitcredentials.txt: mention password alternatives Git asks for a "password", but the user might use a personal access token or OAuth access token instead. Example: Password for 'https://AzureDiamond@github.com': Signed-off-by: M Hickford <mirth.hickford@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 21:46:54 UTC
ee0e7fc fsmonitor--daemon: on macOS support symlink Resolves a problem where symbolic links were not showing up in diff when created or modified. kFSEventStreamEventFlagItemIsSymlink is also treated as a file update. This is because kFSEventStreamEventFlagItemIsFile is not included in FSEvents when creating or deleting symbolic links. For example: $ ln -snf t test fsevent: '/path/to/dir/test', flags=0x40100 ItemCreated|ItemIsSymlink| $ ln -snf ci test fsevent: '/path/to/dir/test', flags=0x40200 ItemIsSymlink|ItemRemoved| fsevent: '/path/to/dir/test', flags=0x40100 ItemCreated|ItemIsSymlink| Signed-off-by: srz_zumix <zumix.cpp@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 21:36:09 UTC
916ebb3 revisions API: extend the nascent REV_INFO_INIT macro Have the REV_INFO_INIT macro added in [1] declare more members of "struct rev_info" that we can initialize statically, and have repo_init_revisions() do so with the memcpy(..., &blank) idiom introduced in [2]. As the comment for the "REV_INFO_INIT" macro notes this still isn't sufficient to initialize a "struct rev_info" for use yet. But we are getting closer to that eventual goal. Even though we can't fully initialize a "struct rev_info" with REV_INFO_INIT it's useful for readability to clearly separate those things that we can statically initialize, and those that we can't. This change could replace the: list_objects_filter_init(&revs->filter); In the repo_init_revisions() with this line, at the end of the REV_INFO_INIT deceleration in revisions.h: .filter = LIST_OBJECTS_FILTER_INIT, \ But doing so would produce a minor conflict with an outstanding topic[3]. Let's skip that for now. I have follow-ups to initialize more of this statically, e.g. changes to get rid of grep_init(). We can initialize more members with the macro in a future series. 1. f196c1e908d (revisions API users: use release_revisions() needing REV_INFO_INIT, 2022-04-13) 2. 5726a6b4012 (*.c *_init(): define in terms of corresponding *_INIT macro, 2021-07-01) 3. https://lore.kernel.org/git/265b292ed5c2de19b7118dfe046d3d9d932e2e89.1667901510.git.ps@pks.im/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 21:34:01 UTC
63357b7 ci: use a newer `github-script` version The old version we currently use runs in node.js v12.x, which is being deprecated in GitHub Actions. The new version uses node.js v16.x. Incidentally, this also avoids the warning about the deprecated `::set-output::` workflow command because the newer version of the `github-script` Action uses the recommended new way to specify outputs. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 20:35:13 UTC
73c768d chainlint: annotate original test definition rather than token stream When chainlint detects problems in a test, such as a broken &&-chain, it prints out the test with "?!FOO?!" annotations inserted at each problem location. However, rather than annotating the original test definition, it instead dumps out a parsed token representation of the test. Since it lacks comments, indentations, here-doc bodies, and so forth, this tokenized representation can be difficult for the test author to digest and relate back to the original test definition. However, now that each parsed token carries positional information, the location of a detected problem can be pinpointed precisely in the original test definition. Therefore, take advantage of this information to annotate the test definition itself rather than annotating the parsed token stream, thus making it easier for a test author to relate a problem back to the source. Maintaining the positional meta-information associated with each detected problem requires a slight change in how the problems are managed internally. In particular, shell syntax such as: msg="total: $(cd data; wc -w *.txt) words" requires the lexical analyzer to recursively invoke the parser in order to detect problems within the $(...) expression inside the double-quoted string. In this case, the recursive parse context will detect the broken &&-chain between the `cd` and `wc` commands, returning the token stream: cd data ; ?!AMP?! wc -w *.txt However, the parent parse context will see everything inside the double-quotes as a single string token: "total: $(cd data ; ?!AMP?! wc -w *.txt) words" losing whatever positional information was attached to the ";" token where the problem was detected. One way to preserve the positional information of a detected problem in a recursive parse context within a string would be to attach the positional information to the annotation textually; for instance: "total: $(cd data ; ?!AMP:21:22?! wc -w *.txt) words" and then extract the positional information when annotating the original test definition. However, a cleaner and much simpler approach is to maintain the list of detected problems separately rather than embedding the problems as annotations directly in the parsed token stream. Not only does this ensure that positional information within recursive parse contexts is not lost, but it keeps the token stream free from non-token pollution, which may simplify implementation of validations added in the future since they won't have to handle non-token "?!FOO!?" items specially. Finally, the chainlint self-test "expect" files need a few mechanical adjustments now that the original test definitions are emitted rather than the parsed token stream. In particular, the following items missing from the historic parsed-token output are now preserved verbatim: * indentation (and whitespace, in general) * comments * here-doc bodies * here-doc tag quoting (i.e. "\EOF") * line-splices (i.e. "\" at the end of a line) Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 20:10:49 UTC
5f0321a chainlint: latch start/end position of each token When chainlint detects problems in a test, such as a broken &&-chain, it prints out the test with "?!FOO?!" annotations inserted at each problem location. However, rather than annotating the original test definition, it instead dumps out a parsed token representation of the test. Since it lacks comments, indentations, here-doc bodies, and so forth, this tokenized representation can be difficult for the test author to digest and relate back to the original test definition. To address this shortcoming, an upcoming change will make it print out an annotated copy of the original test definition rather than the tokenized representation. In order to do so, it will need to know the start and end positions of each token in the original test definition. As preparation, upgrade TestParser::scan_token() to latch the start and end position of the token being scanned, and return that information along with the token itself. A subsequent change will take advantage of this positional information. In terms of implementation, TestParser::scan_token() is retrofitted to return a tuple consisting of the token's lexeme and its start and end positions, rather than returning just the lexeme. However, an alternative would be to define a class which represents a token: package Token; sub new { my ($class, $lexeme, $start, $end) = @_; bless [$lexeme, $start, $end] => $class; } sub as_string { my $self = shift @_; return $self->[0]; } sub compare { my ($x, $y) = @_; if (UNIVERSAL::isa($y, 'Token')) { return $x->[0] cmp $y->[0]; } return $x->[0] cmp $y; } use overload ( '""' => 'as_string', 'cmp' => 'compare' ); The major benefit of the class-based approach is that it is entirely non-invasive; it requires no additional changes to the rest of the script since a Token converts automatically to a string, which is what scan_token() historically returned. The big downside to the Token approach, however, is that it is _slow_; on this developer's (old) machine, it increases user-time by an unacceptable seven seconds when scanning all test scripts in the project. Hence, the simple tuple approach is employed instead since it adds only a fraction of a second user-time. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 20:10:49 UTC
ca748f5 chainlint: tighten accuracy when consuming input stream To extract the next token in the input stream, Lexer::scan_token() finds the start of the token by skipping whitespace, then consumes characters belonging to the token until it encounters a non-token character, such as an operator, punctuation, or whitespace. In the case of an operator or punctuation which ends a token, before returning the just-scanned token, it pushes that operator or punctuation character back onto the input stream to ensure that it will be the first character consumed by the next call to scan_token(). However, scan_token() is intentionally lax when whitespace ends a token; it doesn't bother pushing the whitespace character back onto the token stream since it knows that the next call to scan_token() will, as its first step, skip over whitespace anyhow when looking for the start of the token. Although such laxity is harmless for the proper functioning of the lexical analyzer, it does make it difficult to precisely identify the token's end position in the input stream. Accurate token position information may be desirable, for instance, to annotate problems or highlight other interesting facets of the input found during the parsing phase. To accommodate such possibilities, tighten scan_token() by making it push the token-ending whitespace character back onto the input stream, just as it does for other token-ending characters. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 20:10:49 UTC
c90d81f chainlint: add explanatory comments The logic in TestParser::accumulate() for detecting broken &&-chains is mostly well-commented, but a couple branches which were deemed obvious and straightforward lack comments. In retrospect, though, these cases may give future readers pause, so comment them, as well. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 20:10:49 UTC
69d9446 submodule--helper: use OPT_SUBCOMMAND() API Have the cmd_submodule__helper() use the OPT_SUBCOMMAND() API introduced in fa83cc834da (parse-options: add support for parsing subcommands, 2022-08-19). This is only a marginal reduction in line count, but once we start unifying this with a yet-to-be-added "builtin/submodule.c" it'll be much easier to reason about those changes, as they'll both use OPT_SUBCOMMAND(). We don't need to worry about "argv[0]" being NULL in the die() because we'd have errored out in parse_options() as we're not using "PARSE_OPT_SUBCOMMAND_OPTIONAL". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 19:55:30 UTC
1b6e200 submodule--helper: drop "update --prefix <pfx>" for "-C <pfx> update" Since 29a5e9e1ffe (submodule--helper update-clone: learn --init, 2022-03-04) we've been passing "-C <prefix>" from "git-submodule.sh" whenever we pass "--prefix <prefix>", so the latter is redundant to the former. Let's drop the "--prefix" option. Suggested-by: Glen Choo <chooglen@google.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 19:55:30 UTC
64f48ad submodule--helper: remove --prefix from "absorbgitdirs" Let's pass the "-C <prefix>" option instead to "absorbgitdirs" from its only caller. When it was added in f6f85861400 (submodule: add absorb-git-dir function, 2016-12-12) there were other "submodule--helper" subcommands that were invoked with "-C <prefix>", so we could have done this all along. Suggested-by: Glen Choo <chooglen@google.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> 08 November 2022, 19:55:30 UTC
back to top