{"thread":{"id":"57925","subject":"What's cooking in git.git (May 2022, #07; Wed, 25)","startedAt":"2022-05-26T08:41:35Z","lastAt":"2022-06-01T15:48:44Z","messageCount":24,"participants":["Junio C Hamano","Victoria Dye","Taylor Blau","Ævar Arnfjörð Bjarmason","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"456153","messageId":"xmqqzgj41ya2.fsf@gitster.g","threadId":"57925","inReplyTo":null,"subject":"What's cooking in git.git (May 2022, #07; Wed, 25)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-26T08:41:25Z","receivedAt":"2022-05-26T08:41:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking in my tree. Commits\nprefixed with '+' are in 'next' (being in 'next' is a sign that a\ntopic is stable enough to be used and are candidate to be in a\nfuture release). Commits prefixed with '-' are only in 'seen',\nand aren't considered \"accepted\" at all.\n\nThis cycle will conclude in early July (https://tinyurl.com/gitCal);\nwe are in the week #5 of the cycle.\n\nCopies of the source code to Git live in many repositories, and the\nfollowing is a list of the ones I push into or their mirrors. Some\nrepositories have only a subset of branches.\n\nWith maint, master, next, seen, todo:\n\n\tgit://git.kernel.org/pub/scm/git/git.git/\n\tgit://repo.or.cz/alt-git.git/\n\thttps://kernel.googlesource.com/pub/scm/git/git/\n\thttps://github.com/git/git/\n\thttps://gitlab.com/git-vcs/git/\n\nWith all the integration branches and topics broken out:\n\n\thttps://github.com/gitster/git/\n\nEven though the preformatted documentation in HTML and man format\nare not sources, they are published in these repositories for\nconvenience (replace \"htmldocs\" with \"manpages\" for the manual\npages):\n\n\tgit://git.kernel.org/pub/scm/git/git-htmldocs.git/\n\thttps://github.com/gitster/git-htmldocs.git/\n\nRelease tarballs are available at:\n\n\thttps://www.kernel.org/pub/software/scm/git/\n\n--------------------------------------------------\n[Graduated to 'master']\n\n* ab/commit-plug-leaks (2022-05-12) 1 commit\n (merged to 'next' on 2022-05-16 at 00bcda44af)\n + commit: fix \"author_ident\" leak\n\n Leakfix in the top-level called-once function.\n source: \n\n\n* ab/valgrind-fixes (2022-05-12) 4 commits\n (merged to 'next' on 2022-05-16 at 75d760528f)\n + commit-graph.c: don't assume that stat() succeeds\n + object-file: fix a unpack_loose_header() regression in 3b6a8db3b03\n + log test: skip a failing mkstemp() test under valgrind\n + tests: using custom GIT_EXEC_PATH breaks --valgrind tests\n (this branch is used by ds/object-file-unpack-loose-header-fix.)\n\n A bit of test framework fixes with a few fixes to issues found by\n valgrind.\n source: <20220512223218.237544-1-gitster@pobox.com>\n\n\n* ep/coverage-report-wants-test-to-have-run (2022-04-13) 1 commit\n (merged to 'next' on 2022-05-18 at e4a51b0867)\n + Makefile: add a prerequisite to the coverage-report target\n\n \"make coverage-report\" without first running \"make coverage\" did\n not produce any meaningful result, which has been corrected.\n source: <20220414022513.31465-1-gitter.spiros@gmail.com>\n\n\n* jc/archive-add-file-normalize-mode (2022-05-12) 1 commit\n (merged to 'next' on 2022-05-16 at 265bb02f2a)\n + archive: do not let on-disk mode leak to zip archives\n\n \"git archive --add-file=\" picked up the raw permission bits\n from the path and propagated to zip output in some cases, without\n normalization, which has been corrected (tar output did not have\n this issue).\n source: \n\n\n* jc/avoid-redundant-submodule-fetch (2022-05-18) 1 commit\n (merged to 'next' on 2022-05-19 at 11dabe678b)\n + fetch: do not run a redundant fetch from submodule\n\n \"git fetch --recurse-submodules\" from multiple remotes (either from\n a remote group, or \"--all\") used to make one extra \"git fetch\" in\n the submodules, which has been corrected.\n source: \n\n\n* jc/show-branch-g-current (2022-04-21) 1 commit\n (merged to 'next' on 2022-05-18 at 870a1a1a71)\n + show-branch: -g and --current are incompatible\n\n The \"--current\" option of \"git show-branch\" should have been made\n incompatible with the \"--reflog\" mode, but this was not enforced,\n which has been corrected.\n source: \n\n\n* jt/fetch-peek-optional-section (2022-05-16) 1 commit\n (merged to 'next' on 2022-05-18 at bc876bd2cf)\n + fetch-pack: make unexpected peek result non-fatal\n\n \"git fetch\" unnecessarily failed when an unexpected optional\n section appeared in the output, which has been corrected.\n source: <20220516110221.3490982-1-jonathantanmy@google.com>\n\n\n* os/fetch-check-not-current-branch (2022-05-16) 1 commit\n (merged to 'next' on 2022-05-19 at f48dca6322)\n + fetch: limit shared symref check only for local branches\n\n The way \"git fetch\" without \"--update-head-ok\" ensures that HEAD in\n no worktree points at any ref being updated was too wasteful, which\n has been optimized a bit.\n source: \n\n\n* pb/ggg-in-mfc-doc (2022-05-12) 5 commits\n (merged to 'next' on 2022-05-19 at e1c148492f)\n + MyFirstContribution: drop PR description for GGG single-patch contributions\n + MyFirstContribution: reference \"The cover letter\" in GitGitGadget section\n + MyFirstContribution: reference \"The cover letter\" in \"Preparing Email\"\n + MyFirstContribution: add standalone section on cover letter\n + MyFirstContribution: add \"Anatomy of a Patch Series\" section\n\n Documentation update.\n source: \n\n\n* tb/receive-pack-code-cleanup (2022-05-18) 1 commit\n (merged to 'next' on 2022-05-19 at 756d64f5a2)\n + builtin/receive-pack.c: remove redundant 'if'\n\n Code clean-up.\n source: \n\n--------------------------------------------------\n[New Topics]\n\n* ds/bundle-uri-more (2022-05-20) 24 commits\n - t5601: basic bundle URI tests\n - clone: unbundle the advertised bundles\n - bundle-uri: download bundles from an advertised list\n - bundle-uri: allow relative URLs in bundle lists\n - bundle-uri client: add boolean transfer.bundleURI setting\n - bundle-uri: serve URI advertisement from bundle.* config\n - bundle-uri client: add \"git ls-remote-bundle-uri\"\n - bundle-uri client: add minimal NOOP client\n - protocol v2: add server-side \"bundle-uri\" skeleton\n - bundle-uri: fetch a list of bundles\n - bundle-uri: parse bundle list in config format\n - bundle-uri: limit recursion depth for bundle lists\n - bundle-uri: unit test \"key=value\" parsing\n - bundle-uri: create \"key=value\" line parsing\n - bundle-uri: create base key-value pair parsing\n - bundle-uri: create bundle_list struct and helpers\n - clone: --bundle-uri cannot be combined with --depth\n - clone: add --bundle-uri option\n - fetch: add 'refs/bundle/' to log.excludeDecoration\n - fetch: add --bundle-uri option\n - bundle-uri: add support for http(s):// and file://\n - bundle-uri: create basic file-copy logic\n - remote-curl: add 'get' capability\n - docs: document bundle URI standard\n (this branch uses ds/bundle-uri.)\n\n source: \n source: \n\n\n* jc/revert-show-parent-info (2022-05-23) 1 commit\n - revert: optionally refer to commit in the \"reference\" format\n\n source: \n\n\n* jc/http-clear-finished-pointer (2022-05-24) 1 commit\n - http.c: clear the 'finished' member once we are done with it\n\n Meant to go with js/ci-gcc-12-fixes\n\n Will merge to 'next'?\n source: \n\n\n* js/ci-gcc-12-fixes (2022-05-24) 3 commits\n - dir.c: avoid \"exceeds maximum object size\" error with GCC v12.x\n - nedmalloc: avoid new compile error\n - compat/win32/syslog: fix use-after-realloc\n\n Fixes real problems noticed by gcc 12 and works around false\n positives.\n\n Will merge to 'next'?\n source: \n\n\n* kl/setup-in-unreadable-worktree (2022-05-24) 1 commit\n - setup: don't die if realpath(3) fails on getcwd(3)\n\n Disable the \"do not remove the directory the user started Git in\"\n logic when Git cannot tell where that directory is. Earlier we\n refused to run in such a case.\n\n Will merge to 'next'.\n source: <8b20840014d214023c50ee62439147f798e6f9cc.1653419993.git.kevin@kevinlocke.name>\n\n\n* pb/use-freebsd-12.3-in-cirrus-ci (2022-05-25) 1 commit\n - ci: update Cirrus-CI image to FreeBSD 12.3\n\n Update the version of FreeBSD image used in Cirrus CI.\n\n Will merge to 'next'.\n source: <20220525125112.86954-1-levraiphilippeblain@gmail.com>\n\n\n* yw/cmake-updates (2022-05-24) 3 commits\n - cmake: remove (_)UNICODE def on Windows in CMakeLists.txt\n - cmake: add pcre2 support\n - cmake: fix CMakeLists.txt on Linux\n\n CMake updates.\n\n Will merge to 'next'?\n source: \n\n\n* sg/build-gitweb (2022-05-25) 1 commit\n - Makefile: build 'gitweb' in the default target\n\n \"make all\" should but didn't build \"gitweb\".\n\n Will merge to 'next'.\n source: <20220525205651.825669-1-szeder.dev@gmail.com>\n\n--------------------------------------------------\n[Stalled]\n\n* en/merge-tree (2022-02-23) 13 commits\n - git-merge-tree.txt: add a section on potentional usage mistakes\n - merge-tree: add a --allow-unrelated-histories flag\n - merge-tree: allow `ls-files -u` style info to be NUL terminated\n - merge-tree: provide easy access to `ls-files -u` style info\n - merge-tree: provide a list of which files have conflicts\n - merge-ort: provide a merge_get_conflicted_files() helper function\n - merge-tree: support including merge messages in output\n - merge-ort: split out a separate display_update_messages() function\n - merge-tree: implement real merges\n - merge-tree: add option parsing and initial shell for real merge function\n - merge-tree: move logic for existing merge into new function\n - merge-tree: rename merge_trees() to trivial_merge_trees()\n - Merge branch 'en/remerge-diff' into en/merge-trees\n\n A new command is introduced that takes two commits and computes a\n tree that would be contained in the resulting merge commit, if the\n histories leading to these two commits were to be merged, and is\n added as a new mode of \"git merge-tree\" subcommand.\n\n On hold.\n cf. \n source: \n\n\n* ab/ci-github-workflow-markup (2022-05-22) 12 commits\n . fixup! ci: make it easier to find failed tests' logs in the GitHub workflow\n . ci: call `finalize_test_case_output` a little later\n . ci: use `--github-workflow-markup` in the GitHub workflow\n . ci: optionally mark up output in the GitHub workflow\n . test(junit): avoid line feeds in XML attributes\n . tests: refactor --write-junit-xml code\n . ci: make it easier to find failed tests' logs in the GitHub workflow\n . CI: stop setting FAILED_TEST_ARTIFACTS N times\n . CI: don't include \"test-results/\" in ci/print-test-failures.sh output\n . CI: add --exit-code to ci/print-test-failures.sh\n . CI: don't \"cd\" in ci/print-test-failures.sh\n . Merge branch 'ab/ci-setup-simplify' into ab/ci-github-workflow-markup\n (this branch uses ab/ci-setup-simplify.)\n\n Build a moral equivalent of js/ci-github-workflow-markup on top of\n ab/ci-setup-simplify.\n source: \n\n\n* ab/ci-setup-simplify (2022-04-21) 29 commits\n . CI: make it easy to use ci/*.sh outside of CI\n . CI: don't use \"set -x\" in \"ci/lib.sh\" output\n . CI: set PYTHON_PATH setting for osx-{clang,gcc} into \"$jobname\" case\n . CI: set SANITIZE=leak in MAKEFLAGS directly\n . CI: set CC in MAKEFLAGS directly, don't add it to the environment\n . CI: add more variables to MAKEFLAGS, except under vs-build\n . CI: narrow down variable definitions in --build and --test\n . CI: only invoke ci/lib.sh as \"steps\" in main.yml\n . CI: pre-select test slice in Windows & VS tests\n . ci/run-test-slice.sh: replace shelling out with \"echo\"\n . CI: move \"env\" definitions into ci/lib.sh\n . CI: combine ci/install{,-docker}-dependencies.sh\n . CI: split up and reduce \"ci/test-documentation.sh\"\n . CI: invoke \"make artifacts-tar\" directly in windows-build\n . CI: check ignored unignored build artifacts in \"win[+VS] build\" too\n . CI: make ci/{lib,install-dependencies}.sh POSIX-compatible\n . CI: remove \"run-build-and-tests.sh\", run \"make [test]\" directly\n . CI: export variables via a wrapper\n . CI: consistently use \"export\" in ci/lib.sh\n . CI: move p4 and git-lfs variables to ci/install-dependencies.sh\n . CI: have \"static-analysis\" run \"check-builtins\", not \"documentation\"\n . CI: have \"static-analysis\" run a \"make ci-static-analysis\" target\n . CI: don't have \"git grep\" invoke a pager in tree content check\n . CI/lib.sh: stop adding leading whitespace to $MAKEFLAGS\n . CI: remove unused Azure ci/* code\n . CI: remove dead \"tree skipping\" code\n . CI: remove more dead Travis CI support\n . CI: make \"$jobname\" explicit, remove fallback\n . CI: run \"set -ex\" early in ci/lib.sh\n (this branch is used by ab/ci-github-workflow-markup.)\n\n Drive more actions done in CI via the Makefile instead of shell\n commands sprinkled in .github/workflows/main.yml\n source: \n\n\n* et/xdiff-indirection (2022-02-17) 1 commit\n - xdiff: provide indirection to git functions\n\n Insert a layer of preprocessor macros for common functions in xdiff\n codebase.\n\n Will discard, as it has been stalled for way too long.\n cf. \n source: <20220217225408.GB7@edef91d97c94>\n\n\n* bc/stash-export (2022-04-08) 4 commits\n - builtin/stash: provide a way to import stashes from a ref\n - builtin/stash: provide a way to export stashes to a ref\n - builtin/stash: factor out revision parsing into a function\n - object-name: make get_oid quietly return an error\n\n A mechanism to export and import stash entries to and from a normal\n commit to transfer it across repositories has been introduced.\n\n Expecting a reroll.\n cf. \n source: <20220407215352.3491567-1-sandals@crustytoothpaste.net>\n\n\n* js/wait-or-whine-can-fail (2022-04-28) 1 commit\n - run-command: don't spam trace2_child_exit()\n\n We used to log an error return from wait_or_whine() as process\n termination of the waited child, which was incorrect.\n\n Needs clarifying \"in rare cases\".\n source: <4616d09ffa632bd2c9e308a713c4bdf2a1328c3c.1651179450.git.steadmon@google.com>\n\n\n* dl/prompt-pick-fix (2022-03-25) 1 commit\n . git-prompt: fix sequencer/todo detection\n\n Fix shell prompt script (in contrib/) for those who set\n rebase.abbreviateCommands; we failed to recognize that we were in a\n multi-step cherry-pick session.\n\n Will discard, as it has been stalled for way too long.\n cf. \n source: <20220325145301.3370-1-danny0838@gmail.com>\n\n\n* es/superproject-aware-submodules (2022-03-09) 3 commits\n . rev-parse: short-circuit superproject worktree when config unset\n . introduce submodule.hasSuperproject record\n . t7400-submodule-basic: modernize inspect() helper\n\n A configuration variable in a repository tells if it is (or is not)\n a submodule of a superproject.\n\n Will discard, as it has been stalled for way too long.\n cf. \n source: <20220310004423.2627181-1-emilyshaffer@google.com>\n\n\n* cw/remote-object-info (2022-05-06) 11 commits\n - SQUASH??? coccicheck\n - SQUASH??? ensure that coccicheck is happy\n - SQUASH??? compilation fix\n - cat-file: add --batch-command remote-object-info command\n - cat-file: move parse_cmd and DEFAULT_FORMAT up\n - transport: add object-info fallback to fetch\n - transport: add client side capability to request object-info\n - object-info: send attribute packet regardless of object ids\n - object-store: add function to free object_info contents\n - fetch-pack: move fetch default settings\n - fetch-pack: refactor packet writing\n\n A client component to talk with the object-info endpoint.\n\n Expecting a reroll.\n source: <20220502170904.2770649-1-calvinwan@google.com>\n\n--------------------------------------------------\n[Cooking]\n\n* js/ci-github-workflow-markup (2022-05-21) 12 commits\n - ci: call `finalize_test_case_output` a little later\n - ci(github): mention where the full logs can be found\n - ci: use `--github-workflow-markup` in the GitHub workflow\n - ci(github): avoid printing test case preamble twice\n - ci(github): skip the logs of the successful test cases\n - ci: optionally mark up output in the GitHub workflow\n - ci/run-build-and-tests: add some structure to the GitHub workflow output\n - ci: make it easier to find failed tests' logs in the GitHub workflow\n - ci/run-build-and-tests: take a more high-level view\n - test(junit): avoid line feeds in XML attributes\n - tests: refactor --write-junit-xml code\n - ci: fix code style\n\n Update the GitHub workflow support to make it quicker to get to the\n failing test.\n\n Will merge to 'next'?\n source: \n\n\n* js/bisect-in-c (2022-05-21) 15 commits\n - bisect: no longer try to clean up left-over `.git/head-name` files\n - bisect: remove Cogito-related code\n - Turn `git bisect` into a full built-in\n - bisect: teach the `bisect--helper` command to show the correct usage strings\n - bisect: move even the command-line parsing to `bisect--helper`\n - bisect--helper: return only correct exit codes in `cmd_*()`\n - bisect--helper: move the `BISECT_STATE` case to the end\n - bisect--helper: make `--bisect-state` optional\n - bisect--helper: align the sub-command order with git-bisect.sh\n - bisect--helper: using `--bisect-state` without an argument is a bug\n - bisect--helper: really retire `--bisect-autostart`\n - bisect--helper: really retire --bisect-next-check\n - bisect--helper: retire the --no-log option\n - bisect: avoid double-quoting when printing the failed command\n - bisect run: fix the error message\n\n Final bits of \"git bisect.sh\" have been rewritten in C.\n\n Will merge to 'next'?\n source: \n\n\n* cb/path-owner-check-with-sudo-plus (2022-05-12) 1 commit\n - git-compat-util: allow root to access both SUDO_UID and root owned\n (this branch uses cb/path-owner-check-with-sudo.)\n\n \"sudo git foo\" used to consider a repository owned by the original\n user a safe one to access; it now also considers a repository owned\n by root a safe one, too (after all, if an attacker can craft a\n malicious repository owned by root, the box is 0wned already).\n source: <20220513010020.55361-1-carenas@gmail.com>\n\n\n* jc/t6424-failing-merge-preserve-local-changes (2022-05-19) 1 commit\n (merged to 'next' on 2022-05-23 at 849cf6f24c)\n + t6424: make sure a failed merge preserves local changes\n\n The tests that ensured merges stop when interfering local changes\n are present did not make sure that local changes are preserved; now\n they do.\n\n Will merge to 'master'.\n source: \n\n\n* tb/geom-repack-with-keep-and-max (2022-05-20) 3 commits\n - builtin/repack.c: ensure that `names` is sorted\n - t7703: demonstrate object corruption with pack.packSizeLimit\n - repack: respect --keep-pack with geometric repack\n\n source: \n\n\n* ab/hooks-regression-fix (2022-05-18) 8 commits\n - hook API: fix v2.36.0 regression: hooks should be connected to a TTY\n - hook API: don't redundantly re-set \"no_stdin\" and \"stdout_to_stderr\"\n - hook tests: fix redirection logic error in 96e7225b310\n - run-command: add an \"ungroup\" option to run_process_parallel()\n - run-command.c: add an initializer for \"struct parallel_processes\"\n - run-command tests: test stdout of run_command_parallel()\n - run-command API: use \"opts\" struct for run_processes_parallel{,_tr2}()\n - run-command tests: change if/if/... to if/else if/else\n\n In Git 2.36 we revamped the way how hooks are invoked. One change\n that is end-user visible is that the output of a hook is no longer\n directly connected to the standard output of \"git\" that spawns the\n hook, which was noticed post release. This is getting corrected.\n source: \n\n\n* tb/midx-race-in-pack-objects (2022-05-24) 4 commits\n - builtin/pack-objects.c: ensure pack validity from MIDX bitmap objects\n - builtin/pack-objects.c: ensure included `--stdin-packs` exist\n - builtin/pack-objects.c: avoid redundant NULL check\n - pack-bitmap.c: check preferred pack validity when opening MIDX bitmap\n\n The multi-pack-index code did not protect the packfile it is going\n to depend on from getting removed while in use, which has been\n corrected.\n\n Will merge to 'next'?\n source: \n\n\n* ds/bundle-uri (2022-05-16) 8 commits\n (merged to 'next' on 2022-05-25 at 43b1b9092c)\n + bundle.h: make \"fd\" version of read_bundle_header() public\n + remote: allow relative_url() to return an absolute url\n + remote: move relative_url()\n + http: make http_get_file() external\n + fetch-pack: move --keep=* option filling to a function\n + fetch-pack: add a deref_without_lazy_fetch_extended()\n + dir API: add a generalized path_match_flags() function\n + connect.c: refactor sending of agent & object-format\n (this branch is used by ds/bundle-uri-more.)\n\n Preliminary code refactoring around transport and bundle code.\n\n Will merge to 'master'.\n source: \n\n\n* ds/sparse-sparse-checkout (2022-05-23) 10 commits\n - sparse-checkout: integrate with sparse index\n - p2000: add test for 'git sparse-checkout [add|set]'\n - sparse-index: complete partial expansion\n - sparse-index: partially expand directories\n - sparse-checkout: --no-sparse-index needs a full index\n - cache-tree: implement cache_tree_find_path()\n - sparse-index: introduce partially-sparse indexes\n - sparse-index: create expand_index()\n - t1092: stress test 'git sparse-checkout set'\n - t1092: refactor 'sparse-index contents' test\n\n \"sparse-checkout\" learns to work well with the sparse-index\n feature.\n\n Will merge to 'next'?\n source: \n\n\n* gc/bare-repo-discovery (2022-05-16) 3 commits\n - SQUASH??? move new test to t0035\n - setup.c: learn discovery.bareRepository=cwd\n - setup.c: make bare repo discovery optional\n\n Introduce a discovery.barerepository configuration variable that\n allows users to forbid discovery of bare repositories.\n\n Expecting a reroll.\n source: \n\n\n* ds/object-file-unpack-loose-header-fix (2022-05-16) 1 commit\n - object-file: convert 'switch' back to 'if'\n\n Coding style fix.\n\n Will merge to 'next'.\n source: <377be0e9-8a0f-4a86-0a66-3b08c0284dae@github.com>\n\n\n* gg/worktree-from-the-above (2022-05-20) 3 commits\n - dir: minor refactoring / clean-up\n - dir: cache git_dir's realpath\n - dir: traverse into repository\n\n With a non-bare repository, with core.worktree pointing at a\n directory that has the repository as its subdirectory, regressed in\n Git 2.27 days.\n\n Needs review.\n source: <20220520192840.8942-1-ggossdev@gmail.com>\n\n\n* ac/remote-v-with-object-list-filters (2022-05-09) 1 commit\n (merged to 'next' on 2022-05-20 at 8d2dc10d8f)\n + builtin/remote.c: teach `-v` to list filters for promisor remotes\n\n \"git remote -v\" now shows the list-objects-filter used during\n fetching from the remote, if available.\n\n Will merge to 'master'.\n source: \n\n\n* cc/http-curlopt-resolve (2022-05-16) 1 commit\n (merged to 'next' on 2022-05-20 at 80a07dc7de)\n + http: add custom hostname to IP address resolutions\n\n With the new http.curloptResolve configuration, the CURLOPT_RESOLVE\n mechanism that allows cURL based applications to use pre-resolved\n IP addresses for the requests is exposed to the scripts.\n\n Will merge to 'master'.\n source: <20220516083851.202057-1-chriscool@tuxfamily.org>\n\n\n* jx/l10n-workflow-change (2022-05-23) 8 commits\n - l10n: Document the new l10n workflow\n - Makefile: add \"po-init\" rule to initialize po/XX.po\n - Makefile: add \"po-update\" rule to update po/XX.po\n - po/git.pot: don't check in result of \"make pot\"\n - i18n CI: stop allowing non-ASCII source messages in po/git.pot\n - Makefile: have \"make pot\" not \"reset --hard\"\n - Makefile: generate \"po/git.pot\" from stable LOCALIZED_C\n - Makefile: sort \"po/git.pot\" by file location\n\n A workflow change for translators are being proposed.\n\n Will merge to 'next'?\n source: <20220523012531.4505-1-worldhello.net@gmail.com>\n\n\n* cb/path-owner-check-with-sudo (2022-05-12) 3 commits\n (merged to 'next' on 2022-05-19 at d282e56560)\n + t0034: add negative tests and allow git init to mostly work under sudo\n + git-compat-util: avoid failing dir ownership checks if running privileged\n + t: regression git needs safe.directory when using sudo\n (this branch is used by cb/path-owner-check-with-sudo-plus.)\n\n With a recent update to refuse access to repositories of other\n people by default, \"sudo make install\" and \"sudo git describe\"\n stopped working. This series intends to loosen it while keeping\n the safety.\n\n Will merge to 'master'.\n source: <20220513010020.55361-1-carenas@gmail.com>\n\n\n* cg/tools-for-git-doc (2022-04-21) 1 commit\n (merged to 'next' on 2022-05-19 at e6b6309afb)\n + Documentation/ToolsForGit.txt: Tools for developing Git\n\n A new doc that lists tips for tools to work with Git's codebase.\n\n Will merge to 'master'.\n source: <20220421084515.21236-2-cogoni.guillaume@gmail.com>\n\n\n* ar/send-email-confirm-by-default (2022-04-22) 1 commit\n - send-email: always confirm by default\n\n \"git send-email\" is changed so that by default it asks for\n confirmation before sending each message out.\n\n Will discard.\n\n I wanted to like this, and had it in the version of Git I use\n myself for daily work, but the prompting turned out to be somewhat\n distracting.\n\n Thoughts?\n source: <20220422083629.1404989-1-hi@alyssa.is>\n\n\n* ab/env-array (2022-05-20) 4 commits\n - run-command API users: use \"env\" not \"env_array\" in comments & names\n - cocci: remove env_array -> env migration\n - run-command API: rename \"env_array\" to \"env\"\n - cocci: add a rename of \"struct child_process\"'s \"env_array\" to \"env\"\n\n Rename .env_array member to .env in the child_process structure.\n\n Expecting a (hopefully final) reroll, before merging it to 'next'.\n cf. \n source: \n\n\n* ab/plug-leak-in-revisions (2022-04-13) 28 commits\n - revisions API: add a TODO for diff_free(&revs->diffopt)\n - revisions API: have release_revisions() release \"topo_walk_info\"\n - revisions API: have release_revisions() release \"date_mode\"\n - revisions API: call diff_free(&revs->pruning) in revisions_release()\n - revisions API: release \"reflog_info\" in release revisions()\n - revisions API: clear \"boundary_commits\" in release_revisions()\n - revisions API: have release_revisions() release \"prune_data\"\n - revisions API: have release_revisions() release \"grep_filter\"\n - revisions API: have release_revisions() release \"filter\"\n - revisions API: have release_revisions() release \"cmdline\"\n - revisions API: have release_revisions() release \"mailmap\"\n - revisions API: have release_revisions() release \"commits\"\n - revisions API users: use release_revisions() for \"prune_data\" users\n - revisions API users: use release_revisions() with UNLEAK()\n - revisions API users: use release_revisions() in builtin/log.c\n - revisions API users: use release_revisions() in http-push.c\n - revisions API users: add \"goto cleanup\" for release_revisions()\n - stash: always have the owner of \"stash_info\" free it\n - revisions API users: use release_revisions() needing REV_INFO_INIT\n - revision.[ch]: document and move code declared around \"init\"\n - revisions API users: add straightforward release_revisions()\n - revision.[ch]: provide and start using a release_revisions()\n - cocci: add and apply free_commit_list() rules\n - format-patch: don't leak \"extra_headers\" or \"ref_message_ids\"\n - string_list API users: use string_list_init_{no,}dup\n - blame: use \"goto cleanup\" for cleanup_scoreboard()\n - t/helper/test-fast-rebase.c: don't leak \"struct strbuf\"\n - Merge branch 'ds/partial-bundle-more' into ab/plug-leak-in-revisions\n\n Plug the memory leaks from the trickiest API of all, the revision\n walker.\n\n Will merge to 'next'?\n source: \n\n\n* ns/batch-fsync (2022-04-06) 13 commits\n (merged to 'next' on 2022-05-23 at 379d8bd500)\n + core.fsyncmethod: performance tests for batch mode\n + t/perf: add iteration setup mechanism to perf-lib\n + core.fsyncmethod: tests for batch mode\n + test-lib-functions: add parsing helpers for ls-files and ls-tree\n + core.fsync: use batch mode and sync loose objects by default on Windows\n + unpack-objects: use the bulk-checkin infrastructure\n + update-index: use the bulk-checkin infrastructure\n + builtin/add: add ODB transaction around add_files_to_cache\n + cache-tree: use ODB transaction around writing a tree\n + core.fsyncmethod: batched disk flushes for loose-objects\n + bulk-checkin: rebrand plug/unplug APIs as 'odb transactions'\n + bulk-checkin: rename 'state' variable and separate 'plugged' boolean\n + Merge branch 'ns/core-fsyncmethod' into ns/batch-fsync\n\n Introduce a filesystem-dependent mechanism to optimize the way the\n bits for many loose object files are ensured to hit the disk\n platter.\n\n Will merge to 'master'.\n source: \n\n\n* en/sparse-cone-becomes-default (2022-04-21) 9 commits\n (merged to 'next' on 2022-05-13 at c168eb55cf)\n + Documentation: some sparsity wording clarifications\n + git-sparse-checkout.txt: mark non-cone mode as deprecated\n + git-sparse-checkout.txt: flesh out pattern set sections a bit\n + git-sparse-checkout.txt: add a new EXAMPLES section\n + git-sparse-checkout.txt: shuffle some sections and mark as internal\n + git-sparse-checkout.txt: update docs for deprecation of 'init'\n + git-sparse-checkout.txt: wording updates for the cone mode default\n + sparse-checkout: make --cone the default\n + tests: stop assuming --no-cone is the default mode for sparse-checkout\n\n Deprecate non-cone mode of the sparse-checkout feature.\n\n Will cook in 'next' til 06-03 and then merge to 'master'.\n source: \n\n\n* tb/cruft-packs (2022-05-25) 18 commits\n - sha1-file.c: don't freshen cruft packs\n - builtin/gc.c: conditionally avoid pruning objects via loose\n - builtin/repack.c: add cruft packs to MIDX during geometric repack\n - builtin/repack.c: use named flags for existing_packs\n - builtin/repack.c: allow configuring cruft pack generation\n - builtin/repack.c: support generating a cruft pack\n - builtin/pack-objects.c: --cruft with expiration\n - reachable: report precise timestamps from objects in cruft packs\n - reachable: add options to add_unseen_recent_objects_to_traversal\n - builtin/pack-objects.c: --cruft without expiration\n - builtin/pack-objects.c: return from create_object_entry()\n - t/helper: add 'pack-mtimes' test-tool\n - pack-mtimes: support writing pack .mtimes files\n - chunk-format.h: extract oid_version()\n - pack-write: pass 'struct packing_data' to 'stage_tmp_packfiles'\n - fixup! pack-mtimes: support reading .mtimes files\n - pack-mtimes: support reading .mtimes files\n - Documentation/technical: add cruft-packs.txt\n\n A mechanism to pack unreachable objects into a \"cruft pack\",\n instead of ejecting them into loose form to be reclaimed later, has\n been introduced.\n\n Will merge to 'next' after squashing fixup! in???\n source: \n\n\n* tk/simple-autosetupmerge (2022-04-29) 3 commits\n (merged to 'next' on 2022-05-19 at 9666852f1e)\n + push: new config option \"push.autoSetupRemote\" supports \"simple\" push\n + push: default to single remote even when not named origin\n + branch: new autosetupmerge option 'simple' for matching branches\n\n \"git -c branch.autosetupmerge=simple branch $A $B\" will set the $B\n as $A's upstream only when $A and $B shares the same name, and \"git\n -c push.default=simple\" on branch $A would push to update the\n branch $A at the remote $B came from. Also more places use the\n sole remote, if exists, before defaulting to 'origin'.\n\n Will merge to 'master'.\n source: \n\n\n* jh/builtin-fsmonitor-part3 (2022-05-25) 31 commits\n - t7527: improve implicit shutdown testing in fsmonitor--daemon\n - fsmonitor--daemon: allow --super-prefix argument\n - t7527: test Unicode NFC/NFD handling on MacOS\n - t/lib-unicode-nfc-nfd: helper prereqs for testing unicode nfc/nfd\n - t/helper/hexdump: add helper to print hexdump of stdin\n - fsmonitor: on macOS also emit NFC spelling for NFD pathname\n - t7527: test FSMonitor on case insensitive+preserving file system\n - fsmonitor: never set CE_FSMONITOR_VALID on submodules\n - t/perf/p7527: add perf test for builtin FSMonitor\n - t7527: FSMonitor tests for directory moves\n - fsmonitor: optimize processing of directory events\n - fsm-listen-darwin: shutdown daemon if worktree root is moved/renamed\n - fsm-health-win32: force shutdown daemon if worktree root moves\n - fsm-health-win32: add polling framework to monitor daemon health\n - fsmonitor--daemon: stub in health thread\n - fsmonitor--daemon: rename listener thread related variables\n - fsmonitor--daemon: prepare for adding health thread\n - fsmonitor--daemon: cd out of worktree root\n - fsm-listen-darwin: ignore FSEvents caused by xattr changes on macOS\n - unpack-trees: initialize fsmonitor_has_run_once in o->result\n - fsmonitor-settings: NTFS and FAT32 on MacOS are incompatible\n - fsmonitor-settings: remote repos on Windows are incompatible\n - fsmonitor-settings: remote repos on macOS are incompatible\n - fsmonitor-settings: stub in macOS-specific incompatibility checking\n - fsmonitor-settings: VFS for Git virtual repos are incompatible\n - fsmonitor-settings: stub in Win32-specific incompatibility checking\n - fsmonitor-settings: bare repos are incompatible with FSMonitor\n - t/helper/fsmonitor-client: create stress test\n - t7527: test FSMonitor on repos with Unicode root paths\n - fsm-listen-win32: handle shortnames\n - Merge branch 'jh/builtin-fsmonitor-part2' into jh/builtin-fsmonitor-part3\n\n More fsmonitor--daemon.\n\n Expecting further work.\n Breaks its own t7527?\n source: \n\n\n* js/scalar-diagnose (2022-05-25) 9 commits\n - fixup! archive --add-virtual-file: allow paths containing colons\n - fixup! archive: optionally add \"virtual\" files\n - scalar: teach `diagnose` to gather loose objects information\n - scalar: teach `diagnose` to gather packfile info\n - scalar diagnose: include disk space information\n - Implement `scalar diagnose`\n - scalar: validate the optional enlistment argument\n - archive --add-virtual-file: allow paths containing colons\n - archive: optionally add \"virtual\" files\n\n Implementation of \"scalar diagnose\" subcommand.\n\n Will merge to 'next'?\n source: \n\n\n* js/use-builtin-add-i (2021-12-01) 2 commits\n (merged to 'next' on 2022-05-23 at a6434bc6f7)\n + add -i: default to the built-in implementation\n + t2016: require the PERL prereq only when necessary\n\n \"git add -i\" was rewritten in C some time ago and has been in\n testing; the reimplementation is now exposed to general public by\n default.\n\n Will merge to 'master'.\n source: \n"},{"id":"456189","messageId":"df44b0cd-bba7-19f0-4e45-c0988239cc4d@github.com","threadId":"57925","inReplyTo":"xmqqzgj41ya2.fsf@gitster.g","subject":"Re: What's cooking in git.git (May 2022, #07; Wed, 25)","fromName":"Victoria Dye","fromEmail":"vdye@github.com","sentAt":"2022-05-26T16:02:27Z","receivedAt":"2022-05-26T16:02:34Z","isPatch":false,"sender":{"key":"vdye@github.com","avatar":"https://avatars.githubusercontent.com/u/3619353?v=4"},"body":"Junio C Hamano wrote:\n> * js/ci-github-workflow-markup (2022-05-21) 12 commits\n> - ci: call `finalize_test_case_output` a little later\n> - ci(github): mention where the full logs can be found\n> - ci: use `--github-workflow-markup` in the GitHub workflow\n> - ci(github): avoid printing test case preamble twice\n> - ci(github): skip the logs of the successful test cases\n> - ci: optionally mark up output in the GitHub workflow\n> - ci/run-build-and-tests: add some structure to the GitHub workflow output\n> - ci: make it easier to find failed tests' logs in the GitHub workflow\n> - ci/run-build-and-tests: take a more high-level view\n> - test(junit): avoid line feeds in XML attributes\n> - tests: refactor --write-junit-xml code\n> - ci: fix code style\n> \n> Update the GitHub workflow support to make it quicker to get to the\n> failing test.\n> \n> Will merge to 'next'?\n> source: \n> \n\nThe latest version of this nicely addressed the feedback I originally had,\nparticularly in improving page loading time. It's still slower than before\nthis series, but IMO it's manageable (especially taking into account the\nimproved information accessibility). \n\nI don't see (or have) any other unaddressed concerns, so I'm in favor of\nmoving it to 'next'.\n\n> * ds/sparse-sparse-checkout (2022-05-23) 10 commits\n> - sparse-checkout: integrate with sparse index\n> - p2000: add test for 'git sparse-checkout [add|set]'\n> - sparse-index: complete partial expansion\n> - sparse-index: partially expand directories\n> - sparse-checkout: --no-sparse-index needs a full index\n> - cache-tree: implement cache_tree_find_path()\n> - sparse-index: introduce partially-sparse indexes\n> - sparse-index: create expand_index()\n> - t1092: stress test 'git sparse-checkout set'\n> - t1092: refactor 'sparse-index contents' test\n> \n> \"sparse-checkout\" learns to work well with the sparse-index\n> feature.\n> \n> Will merge to 'next'?\n> source: \n> \n\nLikewise here - V2 handled all of my nits, and V3 made some helpful\nimprovements to variable naming & documentation. There's nothing else I'm\nwaiting for on this, so I'd be happy to see it merge to 'next'.\n"},{"id":"456196","messageId":"xmqq4k1c1a34.fsf@gitster.g","threadId":"57925","inReplyTo":"df44b0cd-bba7-19f0-4e45-c0988239cc4d@github.com","subject":"Re: What's cooking in git.git (May 2022, #07; Wed, 25)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-26T17:23:59Z","receivedAt":"2022-05-26T17:24:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Victoria Dye writes:\n\n>> * js/ci-github-workflow-markup (2022-05-21) 12 commits\n>> - ci: call `finalize_test_case_output` a little later\n>> - ci(github): mention where the full logs can be found\n>> - ci: use `--github-workflow-markup` in the GitHub workflow\n>> - ci(github): avoid printing test case preamble twice\n>> - ci(github): skip the logs of the successful test cases\n>> - ci: optionally mark up output in the GitHub workflow\n>> - ci/run-build-and-tests: add some structure to the GitHub workflow output\n>> - ci: make it easier to find failed tests' logs in the GitHub workflow\n>> - ci/run-build-and-tests: take a more high-level view\n>> - test(junit): avoid line feeds in XML attributes\n>> - tests: refactor --write-junit-xml code\n>> - ci: fix code style\n>> \n>> Update the GitHub workflow support to make it quicker to get to the\n>> failing test.\n>> \n>> Will merge to 'next'?\n>> source: \n>\n> The latest version of this nicely addressed the feedback I originally had,\n> particularly in improving page loading time. It's still slower than before\n> this series, but IMO it's manageable (especially taking into account the\n> improved information accessibility). \n>\n> I don't see (or have) any other unaddressed concerns, so I'm in favor of\n> moving it to 'next'.\n\nI see Ævar sent another reroll of \"rebuild the base\" and \"then\nrebase a (hopefully) equivalent of this series on top\", but I think\nit is unhealthy to keep doing that. Does the latest \"rebuild the\nbase\" part look unsalvageably and fundamentally bad that it is not\nworth our time to consider joining forces to polish it sufficiently\nand then build this on top?\n\nIf that is the case, then I am OK to merge this to 'next' to cast it\nin stone, and then the let \"rebuild the base\" part once die, to be\nreborn as many \"tweak the way things work to (clarify|optimize) X\"\nfollow-up topics.\n\nThanks.\n"},{"id":"456199","messageId":"Yo/CObnqie21V2Mg@nand.local","threadId":"57925","inReplyTo":"xmqqzgj41ya2.fsf@gitster.g","subject":"tb/cruft-packs (was Re: What's cooking in git.git (May 2022, #07; Wed, 25))","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-05-26T18:08:57Z","receivedAt":"2022-05-26T18:09:04Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Thu, May 26, 2022 at 01:41:25AM -0700, Junio C Hamano wrote:\n> * tb/cruft-packs (2022-05-25) 18 commits\n> - sha1-file.c: don't freshen cruft packs\n> - builtin/gc.c: conditionally avoid pruning objects via loose\n> - builtin/repack.c: add cruft packs to MIDX during geometric repack\n> - builtin/repack.c: use named flags for existing_packs\n> - builtin/repack.c: allow configuring cruft pack generation\n> - builtin/repack.c: support generating a cruft pack\n> - builtin/pack-objects.c: --cruft with expiration\n> - reachable: report precise timestamps from objects in cruft packs\n> - reachable: add options to add_unseen_recent_objects_to_traversal\n> - builtin/pack-objects.c: --cruft without expiration\n> - builtin/pack-objects.c: return from create_object_entry()\n> - t/helper: add 'pack-mtimes' test-tool\n> - pack-mtimes: support writing pack .mtimes files\n> - chunk-format.h: extract oid_version()\n> - pack-write: pass 'struct packing_data' to 'stage_tmp_packfiles'\n> - fixup! pack-mtimes: support reading .mtimes files\n> - pack-mtimes: support reading .mtimes files\n> - Documentation/technical: add cruft-packs.txt\n>\n> A mechanism to pack unreachable objects into a \"cruft pack\",\n> instead of ejecting them into loose form to be reclaimed later, has\n> been introduced.\n>\n> Will merge to 'next' after squashing fixup! in???\n> source: \n\nI think this is ready. This topic has been thoroughly reviewed, and the\noutstanding topics:\n\n - user-facing documentation cautioning about mixed-version cruft GCs\n (similar to what I added in Documentation/technical/cruft-packs.txt\n in v4)\n\n - 64-bit timestamps, if desired\n\nCan easily be done on top. The first one is trivial, and I'll send\nsome patches before getting too close to the -rc phase. The latter is\nmore substantial, but isn't a requirement for merging this (and the\nformat is extensible so this could be done on top if there is\nsignificant interest).\n\nThanks,\nTaylor\n"},{"id":"456200","messageId":"Yo/CeyqsOe7CPY0v@nand.local","threadId":"57925","inReplyTo":"xmqqzgj41ya2.fsf@gitster.g","subject":"Re: What's cooking in git.git (May 2022, #07; Wed, 25)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-05-26T18:10:03Z","receivedAt":"2022-05-26T18:10:09Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Thu, May 26, 2022 at 01:41:25AM -0700, Junio C Hamano wrote:\n> * tb/geom-repack-with-keep-and-max (2022-05-20) 3 commits\n> - builtin/repack.c: ensure that `names` is sorted\n> - t7703: demonstrate object corruption with pack.packSizeLimit\n> - repack: respect --keep-pack with geometric repack\n>\n> source: \n\nStolee took a look at this and left a positive review. Victoria and I\nwrote these patches together, so I assume/hope she's on board, too ;).\n\nI think these are both ready to merge.\n\nThanks,\nTaylor\n"},{"id":"456201","messageId":"Yo/C7suyc6nJS8Tr@nand.local","threadId":"57925","inReplyTo":"xmqqzgj41ya2.fsf@gitster.g","subject":"tb/midx-race-in-pack-objects (was Re: What's cooking in git.git (May 2022, #07; Wed, 25))","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2022-05-26T18:11:58Z","receivedAt":"2022-05-26T18:12:04Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Thu, May 26, 2022 at 01:41:25AM -0700, Junio C Hamano wrote:\n> * tb/midx-race-in-pack-objects (2022-05-24) 4 commits\n> - builtin/pack-objects.c: ensure pack validity from MIDX bitmap objects\n> - builtin/pack-objects.c: ensure included `--stdin-packs` exist\n> - builtin/pack-objects.c: avoid redundant NULL check\n> - pack-bitmap.c: check preferred pack validity when opening MIDX bitmap\n>\n> The multi-pack-index code did not protect the packfile it is going\n> to depend on from getting removed while in use, which has been\n> corrected.\n>\n> Will merge to 'next'?\n> source: \n\nI think these are in good shape, but I'd like for Victoria to take a\nlook at the version on the list here.\n\nWe are running these patches at GitHub, and they have definitively\nclosed the race we were investigating here. But the commit messages\nchanged slightly when going upstream, so I'd appreciate Victoria's (or\nanybody else who is interested) eyes on these.\n\nThanks,\nTaylor\n"},{"id":"456203","messageId":"220526.86leuo5f2g.gmgdl@evledraar.gmail.com","threadId":"57925","inReplyTo":"xmqq4k1c1a34.fsf@gitster.g","subject":"Re: What's cooking in git.git (May 2022, #07; Wed, 25)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-05-26T18:02:50Z","receivedAt":"2022-05-26T18:22:56Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 26 2022, Junio C Hamano wrote:\n\n> Victoria Dye writes:\n>\n>>> * js/ci-github-workflow-markup (2022-05-21) 12 commits\n>>> - ci: call `finalize_test_case_output` a little later\n>>> - ci(github): mention where the full logs can be found\n>>> - ci: use `--github-workflow-markup` in the GitHub workflow\n>>> - ci(github): avoid printing test case preamble twice\n>>> - ci(github): skip the logs of the successful test cases\n>>> - ci: optionally mark up output in the GitHub workflow\n>>> - ci/run-build-and-tests: add some structure to the GitHub workflow output\n>>> - ci: make it easier to find failed tests' logs in the GitHub workflow\n>>> - ci/run-build-and-tests: take a more high-level view\n>>> - test(junit): avoid line feeds in XML attributes\n>>> - tests: refactor --write-junit-xml code\n>>> - ci: fix code style\n>>> \n>>> Update the GitHub workflow support to make it quicker to get to the\n>>> failing test.\n>>> \n>>> Will merge to 'next'?\n>>> source: \n>>\n>> The latest version of this nicely addressed the feedback I originally had,\n>> particularly in improving page loading time. It's still slower than before\n>> this series, but IMO it's manageable (especially taking into account the\n>> improved information accessibility). \n>>\n>> I don't see (or have) any other unaddressed concerns, so I'm in favor of\n>> moving it to 'next'.\n>\n> I see Ævar sent another reroll of \"rebuild the base\" and \"then\n> rebase a (hopefully) equivalent of this series on top\", but I think\n> it is unhealthy to keep doing that.\n\nI'd understood per\nhttps://lore.kernel.org/git/xmqqwnecqdti.fsf@gitster.g/ that you were\nmulling over whether to take my version of js/ci-github-workflow-markup\nor not, and you rightly pointed out some bugs in (at the time) the\nlatest version.\n\nSo I re-rolled the two:\n\n https://lore.kernel.org/git/cover-v6-00.29-00000000000-20220525T094123Z-avarab@gmail.com/\n https://lore.kernel.org/git/cover-v6-00.14-00000000000-20220525T100743Z-avarab@gmail.com/\n\nAs the latter of the two notes there are some outstanding bugs that\nhadn't been noted before in the v3 version of\njs/ci-github-workflow-markup that you currently have queued.\n\nVictoria: This includes a bug in your\nhttps://lore.kernel.org/git/patch-v6-10.14-90a152d79f9-20220525T100743Z-avarab@gmail.com/\nwhere a patch that aims to change the *.markup output alters the *.out\noutput, i.e. the \"raw log\" output now omits output that you were trying\nto omit from the *.markup output.\n\nBut as the performance numbers on my version notes the new GitHub\nfoldable output seems to be around 20% faster on top of my \"base\" topic,\nthe reason being that structurally un-folding \"make\", \"make test\"\netc. to the \"step\" levels is asking the already overworked GitHub CI\nJavaScript to do less work.\n\nAnd while it leaves the new output Johannes is proposing on by default,\nthere's now a facility to disable it:\nhttps://lore.kernel.org/git/patch-v6-14.14-0b02b186c87-20220525T100743Z-avarab@gmail.com/\n\nWhich at least for the time being is something I'm going to use until I\ncan figure out how to speed it up & get the now-missing parts of the raw\nlog output back,\n\n> Does the latest \"rebuild the base\" part look unsalvageably and\n> fundamentally bad that it is not worth our time to consider joining\n> forces to polish it sufficiently and then build this on top?\n\nI think per [1] that Johannes hasn't looked at the \"base\" topic in any\ndetail out of a belief that the two approaches aren't complimentary,\nwhich I think the ~20% improvement in performance (per my re-roll, sent\nsince then) shows that it's worthwhile to combine the two.\n\nI use CI quite heavily, apparently in a way that neither you nor\nJohannes use, because even with that improvement I really don't find the\nnew output worthwhile. I.e. I can open/search the raw logs and sometimes\neven figure out what broke exactly while the new UX will still be at the\nspinning loading icon.\n\nBut as noted above my latest re-roll provides an out for that, you can\njust change your ci-config to use the old output if you'd like, for that\nand reasons I've noted before I'd really prefer to see the combination\nof the two land.\n\nThanks!\n"},{"id":"456206","messageId":"8b57f907-3db1-9fe1-d582-e2d05acbe5ce@github.com","threadId":"57925","inReplyTo":"xmqq4k1c1a34.fsf@gitster.g","subject":"Re: What's cooking in git.git (May 2022, #07; Wed, 25)","fromName":"Victoria Dye","fromEmail":"vdye@github.com","sentAt":"2022-05-26T18:30:49Z","receivedAt":"2022-05-26T18:31:36Z","isPatch":false,"sender":{"key":"vdye@github.com","avatar":"https://avatars.githubusercontent.com/u/3619353?v=4"},"body":"Junio C Hamano wrote:\n> Victoria Dye writes:\n> \n>>> * js/ci-github-workflow-markup (2022-05-21) 12 commits\n>>> - ci: call `finalize_test_case_output` a little later\n>>> - ci(github): mention where the full logs can be found\n>>> - ci: use `--github-workflow-markup` in the GitHub workflow\n>>> - ci(github): avoid printing test case preamble twice\n>>> - ci(github): skip the logs of the successful test cases\n>>> - ci: optionally mark up output in the GitHub workflow\n>>> - ci/run-build-and-tests: add some structure to the GitHub workflow output\n>>> - ci: make it easier to find failed tests' logs in the GitHub workflow\n>>> - ci/run-build-and-tests: take a more high-level view\n>>> - test(junit): avoid line feeds in XML attributes\n>>> - tests: refactor --write-junit-xml code\n>>> - ci: fix code style\n>>>\n>>> Update the GitHub workflow support to make it quicker to get to the\n>>> failing test.\n>>>\n>>> Will merge to 'next'?\n>>> source: \n>>\n>> The latest version of this nicely addressed the feedback I originally had,\n>> particularly in improving page loading time. It's still slower than before\n>> this series, but IMO it's manageable (especially taking into account the\n>> improved information accessibility). \n>>\n>> I don't see (or have) any other unaddressed concerns, so I'm in favor of\n>> moving it to 'next'.\n> \n> I see Ævar sent another reroll of \"rebuild the base\" and \"then\n> rebase a (hopefully) equivalent of this series on top\", but I think\n> it is unhealthy to keep doing that. Does the latest \"rebuild the\n> base\" part look unsalvageably and fundamentally bad that it is not\n> worth our time to consider joining forces to polish it sufficiently\n> and then build this on top?\n> \n\nMy impression of 'ab/ci-setup-simplify' is that its core changes are either\nunrelated to, or at least not mutually exclusive with, the\n'js/ci-github-workflow-markup' series. While Ævar has sent an example/RFC\nwith one series rebased on top of the other, I don't see the two as\ninextricably linked, or even really comparable. Because of that, I don't\nthink it would be fair to either series if we continued to hold up *both*\nbecause of different levels of consensus, review, etc.\n\nAs for my thoughts on each series, I do still think\n'js/ci-github-workflow-markup' is ready for 'next' (for the reasons I sent\nearlier). I think 'ab/ci-setup-simplify' needs more review - especially\ngiven its length and the variety of changes - to ensure it doesn't introduce\nregressions or hurt developer quality-of-life. I've personally had a\ndifficult time making sense of the series enough to review it, so I can't\nconfidently judge it one way or another myself.\n\n> If that is the case, then I am OK to merge this to 'next' to cast it\n> in stone, and then the let \"rebuild the base\" part once die, to be\n> reborn as many \"tweak the way things work to (clarify|optimize) X\"\n> follow-up topics.\n> \n\nI'm not sure 'ab/ci-setup-simplify' would need to \"die\", more that it would\nbe adjusted to rebase on top of an updated 'next' (including\n'js/ci-github-workflow-markup'). That said, a re-sent version focusing on\nits own optimizations/improvements (rather than a comparisons against an IMO\nlargely unrelated series) would almost certainly benefit both the series and\nits readers.\n\n> Thanks.\n\n"},{"id":"456208","messageId":"220526.864k1c5dxn.gmgdl@evledraar.gmail.com","threadId":"57925","inReplyTo":"8b57f907-3db1-9fe1-d582-e2d05acbe5ce@github.com","subject":"Re: What's cooking in git.git (May 2022, #07; Wed, 25)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-05-26T18:40:30Z","receivedAt":"2022-05-26T18:47:24Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 26 2022, Victoria Dye wrote:\n\n> I'm not sure 'ab/ci-setup-simplify' would need to \"die\", more that it\n> would be adjusted to rebase on top of an updated 'next' (including\n> 'js/ci-github-workflow-markup'). That said, a re-sent version focusing\n> on its own optimizations/improvements (rather than a comparisons\n> against an IMO largely unrelated series) would almost certainly\n> benefit both the series and[...]\n\nWe probably just crossed E-Mails, but it would be good to know if your\nassessment that they're \"largely unrelated\" is before or after seeing\nthe numbers I noted at\nhttps://lore.kernel.org/git/220526.86leuo5f2g.gmgdl@evledraar.gmail.com/\n\nI.e. that it improves the performance of js/ci-github-workflow-markup by\n~20%. That's the reason I originally looked at combining the two,\nbecause that series was doing a lot of work to re-implement features we\ncould get \"natively\" in the GitHub CI if we just split certain things by\nsteps, instead of dividing those same things with the \"group\" output.\n\nThere's a few other things where they combine\nnicely. E.g. js/ci-github-workflow-markup contains its own mini-version\nre-invention of ci/print-test-failures.sh, in the combined version it\ncan just use that (adjusted) script to get the same output.\n"},{"id":"456209","messageId":"220526.86zgj43z8e.gmgdl@evledraar.gmail.com","threadId":"57925","inReplyTo":"xmqqzgj41ya2.fsf@gitster.g","subject":"sg/build-gitweb (was: What's cooking in git.git (May 2022, #07; Wed, 25))","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-05-26T18:49:12Z","receivedAt":"2022-05-26T18:50:43Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 26 2022, Junio C Hamano wrote:\n\n> * sg/build-gitweb (2022-05-25) 1 commit\n> - Makefile: build 'gitweb' in the default target\n>\n> \"make all\" should but didn't build \"gitweb\".\n>\n> Will merge to 'next'.\n> source: <20220525205651.825669-1-szeder.dev@gmail.com>\n\nDid you see the discussion about what that costs us in terms of noop\n\"make\" performance? See\nhttps://lore.kernel.org/git/220526.86k0a96sv2.gmgdl@evledraar.gmail.com/\n& https://lore.kernel.org/git/Yo8y3AHWa3PChLwd@coredump.intra.peff.net/\n"},{"id":"456210","messageId":"220526.86v8ts3z2k.gmgdl@evledraar.gmail.com","threadId":"57925","inReplyTo":"xmqqzgj41ya2.fsf@gitster.g","subject":"jc/http-clear-finished-pointer (was: What's cooking in git.git (May 2022, #07; Wed, 25))","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-05-26T18:51:23Z","receivedAt":"2022-05-26T18:53:46Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 26 2022, Junio C Hamano wrote:\n\n> * jc/http-clear-finished-pointer (2022-05-24) 1 commit\n> - http.c: clear the 'finished' member once we are done with it\n>\n> Meant to go with js/ci-gcc-12-fixes\n>\n> Will merge to 'next'?\n> source: \n\nThe end of the proposed commit message says:\n\n [...]Clear the finished member before the control leaves the\n function, which has a side effect of unconfusing compilers like\n recent GCC 12 that is over-eager to warn against such an assignment.\n\nI cannot reproduce this suppressing the warning as noted in past\nexchanges, it's not affected by this \"clear if we set it\" pattern. It\nneeds to be unconditionally cleared.\n\nSo I don't think this actively makes anything worse, but I don't think\nit's doing what you're expecting it to do either.\n"},{"id":"456213","messageId":"220526.86r14g3yya.gmgdl@evledraar.gmail.com","threadId":"57925","inReplyTo":"xmqqzgj41ya2.fsf@gitster.g","subject":"js/bisect-in-c (was: What's cooking in git.git (May 2022, #07; Wed, 25))","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-05-26T18:54:36Z","receivedAt":"2022-05-26T18:56:28Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 26 2022, Junio C Hamano wrote:\n\n> * js/bisect-in-c (2022-05-21) 15 commits\n> - bisect: no longer try to clean up left-over `.git/head-name` files\n> - bisect: remove Cogito-related code\n> - Turn `git bisect` into a full built-in\n> - bisect: teach the `bisect--helper` command to show the correct usage strings\n> - bisect: move even the command-line parsing to `bisect--helper`\n> - bisect--helper: return only correct exit codes in `cmd_*()`\n> - bisect--helper: move the `BISECT_STATE` case to the end\n> - bisect--helper: make `--bisect-state` optional\n> - bisect--helper: align the sub-command order with git-bisect.sh\n> - bisect--helper: using `--bisect-state` without an argument is a bug\n> - bisect--helper: really retire `--bisect-autostart`\n> - bisect--helper: really retire --bisect-next-check\n> - bisect--helper: retire the --no-log option\n> - bisect: avoid double-quoting when printing the failed command\n> - bisect run: fix the error message\n>\n> Final bits of \"git bisect.sh\" have been rewritten in C.\n>\n> Will merge to 'next'?\n> source: \n\nThis topic has outstanding regressions in CLI parsing. I.e. we'll now\noffer to start bisection where we previously errored out on invalid\ncommand usage. See my replies in that thread.\n"},{"id":"456214","messageId":"220526.86mtf43yvo.gmgdl@evledraar.gmail.com","threadId":"57925","inReplyTo":"xmqqzgj41ya2.fsf@gitster.g","subject":"jx/l10n-workflow-change (was: What's cooking in git.git (May 2022, #07; Wed, 25))","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-05-26T18:57:07Z","receivedAt":"2022-05-26T18:57:53Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 26 2022, Junio C Hamano wrote:\n\n> * jx/l10n-workflow-change (2022-05-23) 8 commits\n> - l10n: Document the new l10n workflow\n> - Makefile: add \"po-init\" rule to initialize po/XX.po\n> - Makefile: add \"po-update\" rule to update po/XX.po\n> - po/git.pot: don't check in result of \"make pot\"\n> - i18n CI: stop allowing non-ASCII source messages in po/git.pot\n> - Makefile: have \"make pot\" not \"reset --hard\"\n> - Makefile: generate \"po/git.pot\" from stable LOCALIZED_C\n> - Makefile: sort \"po/git.pot\" by file location\n>\n> A workflow change for translators are being proposed.\n>\n> Will merge to 'next'?\n> source: <20220523012531.4505-1-worldhello.net@gmail.com>\n\nI'm happy with the current (posted today) version of it, and think it\nshould advance.\n"},{"id":"456218","messageId":"xmqqczg0yuz7.fsf@gitster.g","threadId":"57925","inReplyTo":"220526.86zgj43z8e.gmgdl@evledraar.gmail.com","subject":"Re: sg/build-gitweb","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-26T19:06:20Z","receivedAt":"2022-05-26T19:06:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Thu, May 26 2022, Junio C Hamano wrote:\n>\n>> * sg/build-gitweb (2022-05-25) 1 commit\n>> - Makefile: build 'gitweb' in the default target\n>>\n>> \"make all\" should but didn't build \"gitweb\".\n>>\n>> Will merge to 'next'.\n>> source: <20220525205651.825669-1-szeder.dev@gmail.com>\n>\n> Did you see the discussion about what that costs us in terms of noop\n> \"make\" performance? See\n> https://lore.kernel.org/git/220526.86k0a96sv2.gmgdl@evledraar.gmail.com/\n> & https://lore.kernel.org/git/Yo8y3AHWa3PChLwd@coredump.intra.peff.net/\n\nI've already marked it with\n\n * sg/build-gitweb (2022-05-25) 1 commit\n - Makefile: build 'gitweb' in the default target\n \n \"make all\" should but didn't build \"gitweb\".\n \n- Will merge to 'next'.\n+ Will discard.\n+ cf. <220526.86k0a96sv2.gmgdl@evledraar.gmail.com>\n+ cf. \n source: <20220525205651.825669-1-szeder.dev@gmail.com>\n\nThanks for a reminder. More eyes help reduce mistakes.\n\n\n"},{"id":"456222","messageId":"xmqq7d68ytj8.fsf_-_@gitster.g","threadId":"57925","inReplyTo":"220526.86v8ts3z2k.gmgdl@evledraar.gmail.com","subject":"Re* jc/http-clear-finished-pointer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-26T19:37:31Z","receivedAt":"2022-05-26T19:37:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Thu, May 26 2022, Junio C Hamano wrote:\n>\n>> * jc/http-clear-finished-pointer (2022-05-24) 1 commit\n>> - http.c: clear the 'finished' member once we are done with it\n>>\n>> Meant to go with js/ci-gcc-12-fixes\n>>\n>> Will merge to 'next'?\n>> source: \n>\n> The end of the proposed commit message says:\n>\n> [...]Clear the finished member before the control leaves the\n> function, which has a side effect of unconfusing compilers like\n> recent GCC 12 that is over-eager to warn against such an assignment.\n>\n> I cannot reproduce this suppressing the warning as noted in past\n> exchanges, it's not affected by this \"clear if we set it\" pattern. It\n> needs to be unconditionally cleared.\n\nInteresting. I still have conditional clearing in the tree, though\nI was reasonably sure I got rid of the conditional and made it\nalways clear, when I rewrote that part of the log message. After\nall, I ran \"commit --amend\" so that I do not forget the issue after\nsending https://lore.kernel.org/git/xmqqleurlt31.fsf@gitster.g/ X-<.\n\nThanks for catching. What is queued is not what I intended to\nqueue.\n\nBut there is one thing that is puzzling. Ever since this, together\nwith the three patches from Dscho for gcc12, got included in 'seen',\nthe branch started passing the Windows build that used to complain\nand did not work, so at least with the version of gcc12 used over\nthere, it apparently is sufficient to clear only when we are\nresponsible for placing an address that is about to become invalid,\nwhile leaving the pointer we didn't stuff in unmodified.\n\nAs far as I understand, with the most recent analysis by Dscho on\nthe http-push codepath, we can return to the loop while the slot is\nholding a different request that is unrelated to ours that has\nalready finished without recursively calling run_active_slot(), and\nwith the current *(slot->finished)=1 trick, it will successfully\nnotify our loop that our request is done, even though slot->in_use\nis set to true back again when it happens. But by definition, at\nthat point, slot->finished is not used by anybody (obviously not by\nus, but also not by the request that is currently using the slot,\nbecause it hasn't used run_active_slot() and slot->finished is not\ntouched by it), so it is safe to unconditionally clear the member.\n\n----- >8 --------- >8 --------- >8 --------- >8 --------- >8 -----\nSubject: [PATCH v3] http.c: clear the 'finished' member once we are done with it\n\nIn http.c, the run_active_slot() function allows the given \"slot\" to\nmake progress by calling step_active_slots() in a loop repeatedly,\nand the loop is not left until the request held in the slot\ncompletes.\n\nAges ago, we used to use the slot->in_use member to get out of the\nloop, which misbehaved when the request in \"slot\" completes (at\nwhich time, the result of the request is copied away from the slot,\nand the in_use member is cleared, making the slot ready to be\nreused), and the \"slot\" gets reused to service a different request\n(at which time, the \"slot\" becomes in_use again, even though it is\nfor a different request). The loop terminating condition mistakenly\nthought that the original request has yet to be completed.\n\nToday's code, after baa7b67d (HTTP slot reuse fixes, 2006-03-10)\nfixed this issue, uses a separate \"slot->finished\" member that is\nset in run_active_slot() to point to an on-stack variable, and the\ncode that completes the request in finish_active_slot() clears the\non-stack variable via the pointer to signal that the particular\nrequest held by the slot has completed. It also clears the in_use\nmember (as before that fix), so that the slot itself can safely be\nreused for an unrelated request.\n\nOne thing that is not quite clean in this arrangement is that,\nunless the slot gets reused, at which point the finished member is\nreset to NULL, the member keeps the value of &finished, which\nbecomes a dangling pointer into the stack when run_active_slot()\nreturns. Clear the finished member before the control leaves the\nfunction, which has a side effect of unconfusing compilers like\nrecent GCC 12 that is over-eager to warn against such an assignment.\n\nSigned-off-by: Junio C Hamano \n---\n http.c | 26 ++++++++++++++++++++++++++\n 1 file changed, 26 insertions(+)\n\ndiff --git a/http.c b/http.c\nindex 229da4d148..9a98372f74 100644\n--- a/http.c\n+++ b/http.c\n@@ -1367,6 +1367,32 @@ void run_active_slot(struct active_request_slot *slot)\n \t\t\tselect(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);\n \t\t}\n \t}\n+\n+\t/*\n+\t * The value of slot->finished we set before the loop was used\n+\t * to set our \"finished\" variable when our request completed.\n+\t *\n+\t * 1. The slot may not have been reused for another requst\n+\t * yet, in which case it still has &finished.\n+\t *\n+\t * 2. The slot may already be in-use to serve another request,\n+\t * which can further be divided into two cases:\n+\t *\n+\t * (a) If call run_active_slot() hasn't been called for that\n+\t * other request, slot->finished may still have the\n+\t * address of our &finished.\n+\t *\n+\t * (b) If the request did call run_active_slot(), then the\n+\t * call would have updated slot->finished at the beginning\n+\t * of this function, and with the clearing of the member\n+\t * below, we would find that slot->finished is now NULL.\n+\t *\n+\t * In all cases, slot->finished has no useful information to\n+\t * anybody at this point. Some compilers warn us for\n+\t * attempting to smuggle a pointer that is about to become\n+\t * invalid, i.e. &finished. We clear it here to assure them.\n+\t */\n+\tslot->finished = NULL;\n }\n \n static void release_active_slot(struct active_request_slot *slot)\n-- \n2.36.1-306-g0dbcc0e187\n"},{"id":"456223","messageId":"xmqq35gwyth3.fsf@gitster.g","threadId":"57925","inReplyTo":"220526.86r14g3yya.gmgdl@evledraar.gmail.com","subject":"Re: js/bisect-in-c","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-26T19:38:48Z","receivedAt":"2022-05-26T19:38:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Thu, May 26 2022, Junio C Hamano wrote:\n>\n>> * js/bisect-in-c (2022-05-21) 15 commits\n>> - bisect: no longer try to clean up left-over `.git/head-name` files\n>> - bisect: remove Cogito-related code\n>> - Turn `git bisect` into a full built-in\n>> - bisect: teach the `bisect--helper` command to show the correct usage strings\n>> - bisect: move even the command-line parsing to `bisect--helper`\n>> - bisect--helper: return only correct exit codes in `cmd_*()`\n>> - bisect--helper: move the `BISECT_STATE` case to the end\n>> - bisect--helper: make `--bisect-state` optional\n>> - bisect--helper: align the sub-command order with git-bisect.sh\n>> - bisect--helper: using `--bisect-state` without an argument is a bug\n>> - bisect--helper: really retire `--bisect-autostart`\n>> - bisect--helper: really retire --bisect-next-check\n>> - bisect--helper: retire the --no-log option\n>> - bisect: avoid double-quoting when printing the failed command\n>> - bisect run: fix the error message\n>>\n>> Final bits of \"git bisect.sh\" have been rewritten in C.\n>>\n>> Will merge to 'next'?\n>> source: \n>\n> This topic has outstanding regressions in CLI parsing. I.e. we'll now\n> offer to start bisection where we previously errored out on invalid\n> command usage. See my replies in that thread.\n\nPointers?\n"},{"id":"456225","messageId":"xmqqo7zkxdvu.fsf@gitster.g","threadId":"57925","inReplyTo":"xmqq35gwyth3.fsf@gitster.g","subject":"Re: js/bisect-in-c","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-26T20:00:53Z","receivedAt":"2022-05-26T20:01:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>>> Final bits of \"git bisect.sh\" have been rewritten in C.\n>>>\n>>> Will merge to 'next'?\n>>> source: \n>>\n>> This topic has outstanding regressions in CLI parsing. I.e. we'll now\n>> offer to start bisection where we previously errored out on invalid\n>> command usage. See my replies in that thread.\n>\n> Pointers?\n\nI guess you meant this one?\n\nhttps://lore.kernel.org/git/220521.86zgjazuy4.gmgdl@evledraar.gmail.com/\n\n"},{"id":"456228","messageId":"xmqqbkvkxd44.fsf@gitster.g","threadId":"57925","inReplyTo":"Yo/CeyqsOe7CPY0v@nand.local","subject":"Re: What's cooking in git.git (May 2022, #07; Wed, 25)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-26T20:17:31Z","receivedAt":"2022-05-26T20:17:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> On Thu, May 26, 2022 at 01:41:25AM -0700, Junio C Hamano wrote:\n>> * tb/geom-repack-with-keep-and-max (2022-05-20) 3 commits\n>> - builtin/repack.c: ensure that `names` is sorted\n>> - t7703: demonstrate object corruption with pack.packSizeLimit\n>> - repack: respect --keep-pack with geometric repack\n>>\n>> source: \n>\n> Stolee took a look at this and left a positive review. Victoria and I\n> wrote these patches together, so I assume/hope she's on board, too ;).\n\nYup, I did find these patches are OK, too.\n\nThanks.\n"},{"id":"456265","messageId":"xmqqr14fx54f.fsf@gitster.g","threadId":"57925","inReplyTo":"8b57f907-3db1-9fe1-d582-e2d05acbe5ce@github.com","subject":"Re: What's cooking in git.git (May 2022, #07; Wed, 25)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-26T23:10:08Z","receivedAt":"2022-05-26T23:10:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Victoria Dye writes:\n\n>> If that is the case, then I am OK to merge this to 'next' to cast it\n>> in stone, and then the let \"rebuild the base\" part once die, to be\n>> reborn as many \"tweak the way things work to (clarify|optimize) X\"\n>> follow-up topics.\n>> \n> I'm not sure 'ab/ci-setup-simplify' would need to \"die\", more that it would\n> be adjusted to rebase on top of an updated 'next' (including\n> 'js/ci-github-workflow-markup').\n\nYeah, that is much closer to what I meant to say. The one that\nwants to build directly on top of 'master' would need to be retired,\nbecause Dscho's series makes quite a lot of overlapping changes, and\nit no longer would be \"GitHub workflow is built on top of this\nrearchitected foundation\" anymore.\n\n> That said, a re-sent version focusing on\n> its own optimizations/improvements (rather than a comparisons against an IMO\n> largely unrelated series) would almost certainly benefit both the series and\n> its readers.\n\nThanks.\n\n"},{"id":"456287","messageId":"220527.86k0a72klr.gmgdl@evledraar.gmail.com","threadId":"57925","inReplyTo":"xmqqo7zkxdvu.fsf@gitster.g","subject":"Re: js/bisect-in-c","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-05-27T12:52:11Z","receivedAt":"2022-05-27T13:03:51Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 26 2022, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n>\n>>>> Final bits of \"git bisect.sh\" have been rewritten in C.\n>>>>\n>>>> Will merge to 'next'?\n>>>> source: \n>>>\n>>> This topic has outstanding regressions in CLI parsing. I.e. we'll now\n>>> offer to start bisection where we previously errored out on invalid\n>>> command usage. See my replies in that thread.\n>>\n>> Pointers?\n>\n> I guess you meant this one?\n>\n> https://lore.kernel.org/git/220521.86zgjazuy4.gmgdl@evledraar.gmail.com/\n\nYes, sorry about the lack of specific reference upthread.\n\nAs noted after in\nhttps://lore.kernel.org/git/220523.865ylwzgji.gmgdl@evledraar.gmail.com/\nwe're rewriting code in this case that doesn't have test coverage to\ncatch these regressions, so more than just a narrow bugfix I'd really\nlike to see a re-roll that gives some confidence that there aren't other\nsuch issues by first adding missing test coverage.\n"},{"id":"456321","messageId":"nycvar.QRO.7.76.6.2205272235220.349@tvgsbejvaqbjf.bet","threadId":"57925","inReplyTo":"xmqq7d68ytj8.fsf_-_@gitster.g","subject":"Re: Re* jc/http-clear-finished-pointer","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2022-05-27T20:41:09Z","receivedAt":"2022-05-27T20:41:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Thu, 26 May 2022, Junio C Hamano wrote:\n\n> diff --git a/http.c b/http.c\n> index 229da4d148..9a98372f74 100644\n> --- a/http.c\n> +++ b/http.c\n> @@ -1367,6 +1367,32 @@ void run_active_slot(struct active_request_slot *slot)\n> \t\t\tselect(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);\n> \t\t}\n> \t}\n> +\n> +\t/*\n> +\t * The value of slot->finished we set before the loop was used\n> +\t * to set our \"finished\" variable when our request completed.\n> +\t *\n> +\t * 1. The slot may not have been reused for another requst\n> +\t * yet, in which case it still has &finished.\n> +\t *\n> +\t * 2. The slot may already be in-use to serve another request,\n> +\t * which can further be divided into two cases:\n> +\t *\n> +\t * (a) If call run_active_slot() hasn't been called for that\n> +\t * other request, slot->finished may still have the\n> +\t * address of our &finished.\n> +\t *\n> +\t * (b) If the request did call run_active_slot(), then the\n> +\t * call would have updated slot->finished at the beginning\n> +\t * of this function, and with the clearing of the member\n> +\t * below, we would find that slot->finished is now NULL.\n> +\t *\n> +\t * In all cases, slot->finished has no useful information to\n> +\t * anybody at this point. Some compilers warn us for\n> +\t * attempting to smuggle a pointer that is about to become\n> +\t * invalid, i.e. &finished. We clear it here to assure them.\n> +\t */\n> +\tslot->finished = NULL;\n> }\n>\n> static void release_active_slot(struct active_request_slot *slot)\n> --\n> 2.36.1-306-g0dbcc0e187\n\nI just verified that there is currently no other location in Git's code\nthat assigns a non-NULL value to `slot->finished` than\n`run_active_slot()`. Otherwise we would potentially overwrite the value\nhere (which is why I preferred the conditional assignment, which does not\nshut up GCC though). So for now, this solution is safe.\n\nHaving said that, it is quite puzzling that GCC thinks it is safe to\nassign a local variable's pointer to a struct that is then accessed\noutside the current file. This would make it easy to copy and use the\npointer well after the function scope was left. This is _not_ the case in\nGit's source code, but GCC seems that this isn't possible by\n(mis-)interpreting the final `slot->finished = NULL` to mean that the\n`slot->finished = &finished` was safe (because it clearly isn't). In GCC's\ndefense, there is probably a lot of code out there that would no longer\ncompile if they truly enforced the new `-Wdangling-pointer` rule\ncorrectly.\n\nWith all that, here is my ACK.\n\nCiao,\nDscho\n"},{"id":"456332","messageId":"xmqqpmjy1ww6.fsf@gitster.g","threadId":"57925","inReplyTo":"nycvar.QRO.7.76.6.2205272235220.349@tvgsbejvaqbjf.bet","subject":"Re: Re* jc/http-clear-finished-pointer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-27T21:35:53Z","receivedAt":"2022-05-27T21:36:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\nThis analysis and explanation was actually still too conservative.\n\n>> +\t/*\n>> +\t * The value of slot->finished we set before the loop was used\n>> +\t * to set our \"finished\" variable when our request completed.\n>> +\t *\n>> +\t * 1. The slot may not have been reused for another requst\n>> +\t * yet, in which case it still has &finished.\n>> +\t *\n>> +\t * 2. The slot may already be in-use to serve another request,\n>> +\t * which can further be divided into two cases:\n>> +\t *\n>> +\t * (a) If call run_active_slot() hasn't been called for that\n>> +\t * other request, slot->finished may still have the\n>> +\t * address of our &finished.\n>> +\t *\n>> +\t * (b) If the request did call run_active_slot(), then the\n>> +\t * call would have updated slot->finished at the beginning\n>> +\t * of this function, and with the clearing of the member\n>> +\t * below, we would find that slot->finished is now NULL.\n\nGiven that there are only two places that assign to slot->finished\n(one is at the beginning of run_active_slot(), the other is when\nget_active_slot() either allocates a new one or decides to reuse the\none that finish_active_slot() has marked to be no longer in use),\nall in \"reused\" cases, not just 2-(b), but even in case 2-(a),\nslot->finished should be NULL.\n\n>> +\t * In all cases, slot->finished has no useful information to\n>> +\t * anybody at this point. Some compilers warn us for\n>> +\t * attempting to smuggle a pointer that is about to become\n>> +\t * invalid, i.e. &finished. We clear it here to assure them.\n>> +\t */\n>> +\tslot->finished = NULL;\n>> }\n\nThe conclusion is still valid. The slot->finished member will not\nhave any useful information when we get here. It either keeps the\nvalue &finished we stored if the slot wasn't reused, or it has NULL\nif it was reused.\n\n> Having said that, it is quite puzzling that GCC thinks it is safe to\n> assign a local variable's pointer to a struct that is then accessed\n> outside the current file. This would make it easy to copy and use the\n> pointer well after the function scope was left. This is _not_ the case in\n> Git's source code, but GCC seems that this isn't possible by\n> (mis-)interpreting the final `slot->finished = NULL` to mean that the\n> `slot->finished = &finished` was safe (because it clearly isn't).\n\nI do not think it is compiler's job to prevent us from assigning to\nslot->finished, in fear of somebody downstream copying the pointer\naway to a global variable that can be accessed long after we return.\n\nWe can store a pointer to an object we malloc() in a member of a\nstruct, pass the struct to somebody else, who might copy the member\naway in a global variable for their own use later, but when they\ngive control back to us, we may free() the object via the member in\nthe struct. The compiler may see that we free() the pointer we stored\nin the struct, but it would not warn us against doing so.\n\n> With all that, here is my ACK.\n\nThanks.\n"},{"id":"456436","messageId":"220601.86pmjs2679.gmgdl@evledraar.gmail.com","threadId":"57925","inReplyTo":"xmqq7d68ytj8.fsf_-_@gitster.g","subject":"Re: Re* jc/http-clear-finished-pointer","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-06-01T07:26:14Z","receivedAt":"2022-06-01T07:28:34Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, May 26 2022, Junio C Hamano wrote:\n\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> On Thu, May 26 2022, Junio C Hamano wrote:\n>>\n>>> * jc/http-clear-finished-pointer (2022-05-24) 1 commit\n>>> - http.c: clear the 'finished' member once we are done with it\n>>>\n>>> Meant to go with js/ci-gcc-12-fixes\n>>>\n>>> Will merge to 'next'?\n>>> source: \n>>\n>> The end of the proposed commit message says:\n>>\n>> [...]Clear the finished member before the control leaves the\n>> function, which has a side effect of unconfusing compilers like\n>> recent GCC 12 that is over-eager to warn against such an assignment.\n>>\n>> I cannot reproduce this suppressing the warning as noted in past\n>> exchanges, it's not affected by this \"clear if we set it\" pattern. It\n>> needs to be unconditionally cleared.\n>\n> Interesting. I still have conditional clearing in the tree, though\n> I was reasonably sure I got rid of the conditional and made it\n> always clear, when I rewrote that part of the log message. After\n> all, I ran \"commit --amend\" so that I do not forget the issue after\n> sending https://lore.kernel.org/git/xmqqleurlt31.fsf@gitster.g/ X-<.\n>\n> Thanks for catching. What is queued is not what I intended to\n> queue.\n>\n> But there is one thing that is puzzling. Ever since this, together\n> with the three patches from Dscho for gcc12, got included in 'seen',\n> the branch started passing the Windows build that used to complain\n> and did not work, so at least with the version of gcc12 used over\n> there, it apparently is sufficient to clear only when we are\n> responsible for placing an address that is about to become invalid,\n> while leaving the pointer we didn't stuff in unmodified.\n\nI didn't find what specific build(s) you were referring to, but perhaps\nthis is due to an interaction with 9c539d1027d (config.mak.dev:\nalternative workaround to gcc 12 warning in http.c, 2022-04-15)?\nI.e. with DEVELOPER=1 we'd already get past the warning with\ngcc+Windows, presumably (but I haven't confirmed whether the\ndetect-compiler etc. works the same there).\n\n> As far as I understand, with the most recent analysis by Dscho on\n> the http-push codepath, we can return to the loop while the slot is\n> holding a different request that is unrelated to ours that has\n> already finished without recursively calling run_active_slot(), and\n> with the current *(slot->finished)=1 trick, it will successfully\n> notify our loop that our request is done, even though slot->in_use\n> is set to true back again when it happens. But by definition, at\n> that point, slot->finished is not used by anybody (obviously not by\n> us, but also not by the request that is currently using the slot,\n> because it hasn't used run_active_slot() and slot->finished is not\n> touched by it), so it is safe to unconditionally clear the member.\n>\n> ----- >8 --------- >8 --------- >8 --------- >8 --------- >8 -----\n> Subject: [PATCH v3] http.c: clear the 'finished' member once we are done with it\n\nI see this is in \"next\" already, as a follow-up we should have a revert\nof 9c539d1027d (config.mak.dev: alternative workaround to gcc 12 warning\nin http.c, 2022-04-15) which this patch makes redundant.\n"},{"id":"456448","messageId":"xmqq35gov0za.fsf@gitster.g","threadId":"57925","inReplyTo":"220601.86pmjs2679.gmgdl@evledraar.gmail.com","subject":"Re: Re* jc/http-clear-finished-pointer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-01T15:48:25Z","receivedAt":"2022-06-01T15:48:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> ... as a follow-up we should have a revert\n> of 9c539d1027d (config.mak.dev: alternative workaround to gcc 12 warning\n> in http.c, 2022-04-15) which this patch makes redundant.\n\nIt is a good point that 9c539d10 (config.mak.dev: alternative\nworkaround to gcc 12 warning in http.c, 2022-04-15) hides problems.\nUnfortunatelly https://github.com/git/git/runs/6665825113 dies early\nwithout reaching the point where it touches http.c X-< so we cannot\ntell.\n\nI am OK to do a revert of the redundant one on 'next', which should\ngive us a confirmation that the particular version of GCC12 is OK\nwith the code we happen to have and letting its -Wdangling-pointer\ntrigger would not harm us with any other false positives. Then we\ncan do the same on the 'master' front with that revert with Dscho's\nother three GCC12 fixes (they are fixes, like the \"realloc then use\"\none) graduating first (which should break http.c) and then the patch\nin this thread as separate steps, if we really wanted to.\n\nThanks.\n"}]}