{"thread":{"id":"60057","subject":"What's cooking in git.git (Aug 2023, #01; Wed, 2)","startedAt":"2023-08-02T18:11:09Z","lastAt":"2023-08-17T13:23:32Z","messageCount":15,"participants":["Junio C Hamano","Taylor Blau","Christian Couder","Elijah Newren","Rubén Justo","Jeff King","Jonathan Tan","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"480098","messageId":"xmqqfs518gdh.fsf@gitster.g","threadId":"60057","inReplyTo":null,"subject":"What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-08-02T18:10:34Z","receivedAt":"2023-08-02T18:11:09Z","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', and\naren't considered \"accepted\" at all and may be annotated with an URL\nto a message that raises issues but they are no means exhaustive. A\ntopic without enough support may be discarded after a long period of\nno activity (of course they can be resubmit when new interests\narise).\n\nWe are getting closer to the final phase of this cycle, which begins\nwhen -rc0 preview release is tagged this coming Friday, followed by\nabout 1 1/2 weeks of stabilization period that begins when -rc1 is\ntagged (cf. tinyurl.com/gitCal). There are a handful of topics that\nstill need reviews before getting merged to 'next', but because the\nsummer in the northern hemisphere is historically a slower season,\ntoo few reviewers seem to be active, relative to the number of these\ntopics.\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* ah/autoconf-fixes (2023-07-19) 3 commits\n (merged to 'next' on 2023-07-25 at 35ff66e0cb)\n + configure.ac: always save NO_ICONV to config.status\n + configure.ac: don't overwrite NO_CURL option\n + configure.ac: don't overwrite NO_EXPAT option\n\n \"./configure --with-expat=no\" did not work as a way to refuse use\n of the expat library on a system with the library installed, which\n has been corrected.\n source: <20230719145211.17854-2-aherrmann@suse.de>\n\n\n* ah/sequencer-rewrite-todo-fix (2023-07-24) 1 commit\n (merged to 'next' on 2023-07-26 at 24e74d9eda)\n + sequencer: finish parsing the todo list despite an invalid first line\n\n When the user edits \"rebase -i\" todo file so that it starts with a\n \"fixup\", which would make it invalid, the command truncated the\n rest of the file before giving an error and returning the control\n back to the user. Stop truncating to make it easier to correct\n such a malformed todo file.\n cf. \n source: <20230722212830.132135-2-alexhenrie24@gmail.com>\n\n\n* bb/use-trace2-counters-for-fsync-stats (2023-07-20) 1 commit\n (merged to 'next' on 2023-07-26 at f2c2e3f2b9)\n + wrapper: use trace2 counters to collect fsync stats\n\n Instead of inventing a custom counter variables for debugging,\n use existing trace2 facility in the fsync customization codepath.\n source: <20230720164823.625815-1-dev+git@drbeat.li>\n\n\n* jc/tree-walk-drop-base-offset (2023-07-07) 2 commits\n (merged to 'next' on 2023-07-25 at cc050c60a6)\n + tree-walk: drop unused base_offset from do_match()\n + tree-walk: lose base_offset that is never used in tree_entry_interesting\n\n Code simplification.\n source: <20230707222116.4129415-1-gitster@pobox.com>\n\n\n* ks/ref-filter-describe (2023-07-24) 2 commits\n (merged to 'next' on 2023-07-26 at f4b3b3b7ef)\n + ref-filter: add new \"describe\" atom\n + ref-filter: add multiple-option parsing functions\n\n \"git branch --list --format=\" and friends are taught\n a new \"%(describe)\" placeholder.\n source: <20230723162717.68123-1-five231003@gmail.com>\n\n--------------------------------------------------\n[New Topics]\n\n* bc/ident-dot-is-no-longer-crud-letter (2023-08-02) 1 commit\n - ident: don't consider '.' a crud\n\n Exclude \".\" from the set of characters to be removed from the\n beginning and the end of the human-readable name.\n\n Will merge to 'next'?\n source: \n\n\n* jc/unresolve-removal (2023-07-31) 7 commits\n - checkout: allow \"checkout -m path\" to unmerge removed paths\n - checkout/restore: add basic tests for --merge\n - checkout/restore: refuse unmerging paths unless checking out of the index\n - update-index: remove stale fallback code for \"--unresolve\"\n - update-index: use unmerge_index_entry() to support removal\n - resolve-undo: allow resurrecting conflicted state that resolved to deletion\n - update-index: do not read HEAD and MERGE_HEAD unconditionally\n\n \"checkout --merge -- path\" and \"update-index --unresolve path\" did\n not resurrect conflicted state that was resolved to remove path,\n but now they do.\n\n Needs review.\n source: <20230731224409.4181277-1-gitster@pobox.com>\n\n\n* ew/hash-with-openssl-evp (2023-08-01) 2 commits\n - avoid SHA-1 functions deprecated in OpenSSL 3+\n - sha256: avoid functions deprecated in OpenSSL 3+\n\n Adjust to OpenSSL 3+, which deprecates its SHA-1 functions based on\n its traditional API, by using its EVP API instead.\n\n Will merge to 'next'. \n source: <20230801025454.1137802-1-e@80x24.org>\n\n\n* rj/status-bisect-while-rebase (2023-08-01) 1 commit\n - status: fix branch shown when not only bisecting\n\n \"git status\" is taught to show both the branch being bisected and\n being rebased when both are in effect at the same time.\n\n Needs review.\n source: <48745298-f12b-8efb-4e48-90d2c22a8349@gmail.com>\n\n--------------------------------------------------\n[Stalled]\n\n* tk/cherry-pick-sequence-requires-clean-worktree (2023-06-01) 1 commit\n - cherry-pick: refuse cherry-pick sequence if index is dirty\n\n \"git cherry-pick A\" that replays a single commit stopped before\n clobbering local modification, but \"git cherry-pick A..B\" did not,\n which has been corrected.\n\n Expecting a reroll.\n cf. <999f12b2-38d6-f446-e763-4985116ad37d@gmail.com>\n source: \n\n\n* ab/tag-object-type-errors (2023-05-10) 4 commits\n - tag: don't emit potentially incorrect \"object is a X, not a Y\"\n - tag: don't misreport type of tagged objects in errors\n - object tests: add test for unexpected objects in tags\n - Merge branch 'jk/parse-object-type-mismatch' into ab/tag-object-type-errors\n\n Hardening checks around mismatched object types when one of those\n objects is a tag.\n\n Will discard.\n Stalled for too long.\n source: \n\n\n* ob/revert-of-revert (2023-05-05) 1 commit\n - sequencer: beautify subject of reverts of reverts\n\n Instead of \"Revert \"Revert \"original\"\", give \"Reapply \"original\"\"\n as the title for a revert of a revert.\n\n Will discard.\n Have been expecting a hopefully final reroll for too long.\n Looking much better, except for minor cosmetic issues.\n cf. \n source: <20230428083528.1699221-1-oswald.buddenhagen@gmx.de>\n\n\n* pw/rebase-i-after-failure (2023-08-01) 7 commits\n - rebase -i: fix adding failed command to the todo list\n - rebase --continue: refuse to commit after failed command\n - rebase: fix rewritten list for failed pick\n - sequencer: factor out part of pick_commits()\n - sequencer: use rebase_path_message()\n - rebase -i: remove patch file after conflict resolution\n - rebase -i: move unlink() calls\n\n Various fixes to the behaviour of \"rebase -i\" when the command got\n interrupted by conflicting changes.\n\n Will merge to 'next'?\n cf. \n cf. \n source: \n\n--------------------------------------------------\n[Cooking]\n\n* ew/sha256-gcrypt-leak-fixes (2023-07-31) 3 commits\n (merged to 'next' on 2023-08-01 at eed83801c3)\n + sha256/gcrypt: die on gcry_md_open failures\n + sha256/gcrypt: fix memory leak with SHA-256 repos\n + sha256/gcrypt: fix build with SANITIZE=leak\n\n Leakfixes.\n\n Will merge to 'master'.\n source: <20230731120808.1230210-1-e@80x24.org>\n\n\n* rs/bundle-parseopt-cleanup (2023-07-31) 1 commit\n (merged to 'next' on 2023-08-01 at 405eb138fa)\n + bundle: use OPT_PASSTHRU_ARGV\n\n Code clean-up.\n\n Will merge to 'master'.\n source: <2dcb915f-b926-e024-6394-23aff200955c@web.de>\n\n\n* pv/doc-submodule-update-settings (2023-07-25) 1 commit\n (merged to 'next' on 2023-07-27 at e27b5b7ba8)\n + doc: highlight that .gitmodules does not support !command\n\n Rewrite the description of giving a custom command to the\n submodule..update configuraiton variable.\n\n Will merge to 'master'.\n source: <20230725212218.711116-1-pvutov@imap.cc>\n\n\n* la/doc-choose-starting-point-fixup (2023-07-27) 3 commits\n (merged to 'next' on 2023-07-28 at 047dcae31c)\n + SubmittingPatches: use of older maintenance tracks is an exception\n + SubmittingPatches: explain why 'next' and above are inappropriate base\n + SubmittingPatches: choice of base for fixing an older maintenance track\n (this branch uses la/doc-choose-starting-point.)\n\n Clarify how to pick a starting point for a new topic in the\n SubmittingPatches document.\n\n Will merge to 'master', together with the underlying topic.\n source: \n source: \n\n\n* am/doc-sha256 (2023-07-31) 1 commit\n (merged to 'next' on 2023-08-01 at d7419bf527)\n + doc: sha256 is no longer experimental\n\n Tone down the warning on SHA-256 repositories being an experimental\n curiosity. We do not have support for them to interoperate with\n traditional SHA-1 repositories, but at this point, we do not plan\n to make breaking changes to SHA-256 repositories and there is no\n longer need for such a strongly phrased warning.\n\n Will merge to 'master'.\n source: \n\n\n* hy/blame-in-bare-with-contents (2023-07-21) 1 commit\n (merged to 'next' on 2023-07-31 at 39ac96d8d8)\n + blame: allow --contents to work with bare repo\n\n \"git blame --contents=file\" has been taught to work in a bare\n repository.\n\n Will merge to 'master'.\n source: <20230721035758.61956-1-hanyang.tony@bytedance.com>\n\n\n* ja/worktree-orphan-fix (2023-07-26) 3 commits\n (merged to 'next' on 2023-07-27 at e475016065)\n + t2400: rewrite regex to avoid unintentional PCRE\n + builtin/worktree.c: convert tab in advice to space\n + t2400: drop no-op `--sq` from rev-parse call\n\n Fix tests with unportable regex patterns.\n\n Will merge to 'master'.\n source: <20230726214202.15775-1-jacobabel@nullpo.dev>\n\n\n* jc/retire-get-sha1-hex (2023-07-24) 1 commit\n (merged to 'next' on 2023-07-27 at eeb9cc37f5)\n + hex: retire get_sha1_hex()\n\n The implementation of \"get_sha1_hex()\" that reads a hexadecimal\n string that spells a full object name has been extended to cope\n with any hash function used in the repository, but the \"sha1\" in\n its name survived. Rename it to get_hash_hex(), a name that is\n more consistent within its friends like get_hash_hex_algop().\n\n Will merge to 'master'.\n source: \n\n\n* rs/parse-options-negation-help (2023-07-24) 5 commits\n - parse-options: show negatability of options in short help\n - t1502: test option negation\n - t1502: move optionspec help output to a file\n - t1502, docs: disallow --no-help\n - subtree: disallow --no-{help,quiet,debug,branch,message}\n\n \"git cmd -h\" learned to signal which options can be negated by\n listing such options like \"--[no-]opt\".\n\n Comments?\n Would showing \"--[[no-]no-]opt\" for \"no-opt\" be worth it?\n cf. <9e8225dd-1e8b-8af2-c3e1-0c5834694244@web.de>\n source: <4d01e971-07cb-4f11-3cc6-9d9f21e590c1@web.de>\n\n\n* tb/commit-graph-tests (2023-07-24) 5 commits\n (merged to 'next' on 2023-07-31 at 740a260315)\n + t/lib-commit-graph.sh: avoid sub-shell in `graph_git_behavior()`\n + t5328: avoid top-level directory changes\n + t5318: avoid top-level directory changes\n + t/lib-commit-graph.sh: avoid directory change in `graph_git_behavior()`\n + t/lib-commit-graph.sh: allow `graph_read_expect()` in sub-directories\n\n Test updates.\n\n Will merge to 'master'.\n source: \n\n\n* la/doc-choose-starting-point (2023-07-14) 5 commits\n (merged to 'next' on 2023-07-19 at 5a807cae46)\n + SubmittingPatches: simplify guidance for choosing a starting point\n + SubmittingPatches: emphasize need to communicate non-default starting points\n + SubmittingPatches: de-emphasize branches as starting points\n + SubmittingPatches: discuss subsystems separately from git.git\n + SubmittingPatches: reword awkward phrasing\n (this branch is used by la/doc-choose-starting-point-fixup.)\n\n Clarify how to choose the starting point for a new topic in\n developer guidance document.\n\n Will merge to 'master' together with the follow-on topic.\n source: \n\n\n* jc/doc-sent-patch-now-what (2023-07-27) 1 commit\n (merged to 'next' on 2023-07-31 at 51f5d9d465)\n + MyFirstContribution: refrain from self-iterating too much\n\n Process document update.\n\n Will merge to 'master'.\n source: \n\n\n* jc/parse-options-short-help (2023-07-19) 3 commits\n (merged to 'next' on 2023-07-31 at e076d1f497)\n + short help: allow a gap smaller than USAGE_GAP\n + remote: simplify \"remote add --tags\" help text\n + short help: allow multi-line opthelp\n\n Command line parser fix, and a small parse-options API update.\n\n Will merge to 'master'.\n source: \n\n\n* sl/sparse-check-attr (2023-07-18) 3 commits\n - check-attr: integrate with sparse-index\n - attr.c: read attributes in a sparse directory\n - t1092: add tests for 'git check-attr'\n\n Teach \"git check-attr\" work better with sparse-index.\n\n Expecting a reroll.\n cf. \n cf. <5e478d8b-9ef4-864b-41e4-e0a79877d278@github.com>\n source: <20230718232916.31660-1-cheskaqiqi@gmail.com>\n\n\n* jc/branch-in-use-error-message (2023-07-21) 1 commit\n (merged to 'next' on 2023-07-31 at 22f17d131b)\n + branch: update the message to refuse touching a branch in-use\n\n \"git branch -f X\" to repoint the branch X seid that X was \"checked\n out\" in another worktree, even when branch X was not and instead\n being bisected or rebased. The message was reworded to say the\n branch was \"in use\".\n\n Will merge to 'master'.\n source: \n\n\n* mh/credential-erase-improvements-more (2023-07-26) 2 commits\n - credential/wincred: erase matching creds only\n - credential/libsecret: erase matching creds only\n\n Update two credential helpers to correctly match which credential\n to erase; they dropped not the ones with stale password.\n\n Needs review.\n source: \n source: \n\n\n* cc/repack-sift-filtered-objects-to-separate-pack (2023-07-24) 8 commits\n . gc: add `gc.repackFilterTo` config option\n . repack: implement `--filter-to` for storing filtered out objects\n . gc: add `gc.repackFilter` config option\n . repack: add `--filter=` option\n . repack: refactor finding pack prefix\n . repack: refactor finishing pack-objects command\n . t/helper: add 'find-pack' test-tool\n . pack-objects: allow `--filter` without `--stdout`\n\n \"git repack\" machinery learns to pay attention to the \"--filter=\"\n option.\n\n Breaks CI with some environment variables configured.\n cf. \n source: <20230724085909.3831831-1-christian.couder@gmail.com>\n\n\n* js/doc-unit-tests (2023-06-30) 1 commit\n - unit tests: Add a project plan document\n\n Process to add some form of low-level unit tests has started.\n\n Still filling in blanks.\n source: <0169ce6fb9ccafc089b74ae406db0d1a8ff8ac65.1688165272.git.steadmon@google.com>\n\n\n* jt/path-filter-fix (2023-08-01) 7 commits\n - commit-graph: new filter ver. that fixes murmur3\n - repo-settings: introduce commitgraph.changedPathsVersion\n - t4216: test changed path filters with high bit paths\n - t/helper/test-read-graph: implement `bloom-filters` mode\n - bloom.h: make `load_bloom_filter_from_graph()` public\n - t/helper/test-read-graph.c: extract `dump_graph_info()`\n - gitformat-commit-graph: describe version 2 of BDAT\n\n The Bloom filter used for path limited history traversal was broken\n on systems whose \"char\" is unsigned; update the implementation and\n bump the format version to 2.\n\n Still under discussion.\n cf. <20230801185232.1457172-1-jonathantanmy@google.com>\n source: \n\n\n* mh/credential-libsecret-attrs (2023-06-16) 1 commit\n - credential/libsecret: store new attributes\n\n The way authentication related data other than passwords (e.g.\n oath token and password expiration data) are stored in libsecret\n keyrings has been rethought.\n\n Needs review.\n source: \n\n\n* cc/git-replay (2023-06-03) 15 commits\n - replay: stop assuming replayed branches do not diverge\n - replay: add --contained to rebase contained branches\n - replay: add --advance or 'cherry-pick' mode\n - replay: disallow revision specific options and pathspecs\n - replay: use standard revision ranges\n - replay: make it a minimal server side command\n - replay: remove HEAD related sanity check\n - replay: remove progress and info output\n - replay: add an important FIXME comment about gpg signing\n - replay: don't simplify history\n - replay: introduce pick_regular_commit()\n - replay: die() instead of failing assert()\n - replay: start using parse_options API\n - replay: introduce new builtin\n - t6429: remove switching aspects of fast-rebase\n\n What's the status of this thing?\n source: <20230602102533.876905-1-christian.couder@gmail.com>\n\n--------------------------------------------------\n[Discarded]\n\n* jc/doc-submodule-update-settings (2023-07-13) 1 commit\n . submodule: clarify that \"!custom command\" is the only oddball\n\n Rewrite the description of giving a custom command to the\n submodule..update configuraiton variable.\n\n Superseded by pv/doc-submodule-update-settings topic.\n source: \n\n\n* jc/rerere-read-rr-fix (2023-07-21) 1 commit\n . rerere: match the hash algorithm with its length\n\n SHA-256 fix.\n\n Superseded by jc/retire-get-sha1-hex\n source: \n\n\n* cb/checkout-same-branch-twice (2023-03-22) 2 commits\n . SQUASH??? the test marked to expect failure passes from day one\n . checkout/switch: disallow checking out same branch in multiple worktrees\n\n \"git checkout -B $branch\" failed to protect against checking out\n a branch that is checked out elsewhere, unlike \"git branch -f\" did.\n\n Have been expecting a hopefully minor and final reroll for too long.\n cf. \n source: <20230120113553.24655-1-carenas@gmail.com>\n\n\n* ed/fsmonitor-windows-named-pipe (2023-03-24) 1 commit\n . fsmonitor: handle differences between Windows named pipe functions\n\n Fix fsmonitor on Windows when the filesystem path contains certain\n characters.\n\n Have been expecting a reroll for too long.\n cf. \n source: \n\n\n* rn/sparse-diff-index (2023-04-10) 1 commit\n . diff-index: enable sparse index\n\n \"git diff-index\" command has been taught to work better with the\n sparse index.\n\n Have been expecting a reroll for too long.\n cf. <62821012-4fc3-5ad8-695c-70f7ab14a8c9@github.com>\n source: <20230408112342.404318-1-nanth.raghul@gmail.com>\n\n\n* es/recurse-submodules-option-is-a-bool (2023-04-10) 1 commit\n . usage: clarify --recurse-submodules as a boolean\n\n The \"--[no-]recurse-submodules\" option of \"git checkout\" and others\n supported an undocumented syntax --recurse-submodules= where\n the value can spell a Boolean in various ways. The support for the\n syntax is being dropped.\n\n Have been expecting a reroll for too long.\n cf. \n source: \n\n\n* jc/checkout-merge-fix (2023-07-28) 2 commits\n . checkout/restore: add basic tests for --merge\n . checkout/restore: refuse unmerging paths unless checking out of the index\n\n \"git checkout/restore --merge -- $path\" improvements.\n\n Superseded by jc/unresolve-removal\n source: \n\n\n* jc/resolve-undo-fixes (2023-07-28) 4 commits\n . update-index: remove stale fallback code for \"--unresolve\"\n . update-index: use unmerge_index_entry() to support removal\n . resolve-undo: allow resurrecting conflicted state that resolved to deletion\n . update-index: do not read HEAD and MERGE_HEAD unconditionally\n\n Assorted fixes and clean-up around resolve-undo data.\n\n Superseded by jc/unresolve-removal\n source: \n"},{"id":"480100","messageId":"ZMqp6K2iXixWH/zT@nand.local","threadId":"60057","inReplyTo":"xmqqfs518gdh.fsf@gitster.g","subject":"jt/path-filter-fix (was: Re: What's cooking in git.git (Aug 2023, #01; Wed, 2))","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2023-08-02T19:09:28Z","receivedAt":"2023-08-02T19:09:35Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Aug 02, 2023 at 11:10:34AM -0700, Junio C Hamano wrote:\n> * jt/path-filter-fix (2023-08-01) 7 commits\n> - commit-graph: new filter ver. that fixes murmur3\n> - repo-settings: introduce commitgraph.changedPathsVersion\n> - t4216: test changed path filters with high bit paths\n> - t/helper/test-read-graph: implement `bloom-filters` mode\n> - bloom.h: make `load_bloom_filter_from_graph()` public\n> - t/helper/test-read-graph.c: extract `dump_graph_info()`\n> - gitformat-commit-graph: describe version 2 of BDAT\n>\n> The Bloom filter used for path limited history traversal was broken\n> on systems whose \"char\" is unsigned; update the implementation and\n> bump the format version to 2.\n>\n> Still under discussion.\n> cf. <20230801185232.1457172-1-jonathantanmy@google.com>\n> source: \n\nI am happy with the most recent round, but I think that it is probably a\nlittle late in the cycle to be merging down such a large change.\n\nI wouldn't be opposed if you did so, but it may be worth waiting until\nwe're on the other side of 2.42 so that other reviewers have a chance to\nlook at this one as well.\n\nThanks,\nTaylor\n"},{"id":"480101","messageId":"xmqqy1it6ykm.fsf@gitster.g","threadId":"60057","inReplyTo":"ZMqp6K2iXixWH/zT@nand.local","subject":"Re: jt/path-filter-fix","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-08-02T19:20:25Z","receivedAt":"2023-08-02T19:20:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Taylor Blau writes:\n\n> On Wed, Aug 02, 2023 at 11:10:34AM -0700, Junio C Hamano wrote:\n>> * jt/path-filter-fix (2023-08-01) 7 commits\n>> - commit-graph: new filter ver. that fixes murmur3\n>> - repo-settings: introduce commitgraph.changedPathsVersion\n>> - t4216: test changed path filters with high bit paths\n>> - t/helper/test-read-graph: implement `bloom-filters` mode\n>> - bloom.h: make `load_bloom_filter_from_graph()` public\n>> - t/helper/test-read-graph.c: extract `dump_graph_info()`\n>> - gitformat-commit-graph: describe version 2 of BDAT\n>>\n>> The Bloom filter used for path limited history traversal was broken\n>> on systems whose \"char\" is unsigned; update the implementation and\n>> bump the format version to 2.\n>>\n>> Still under discussion.\n>> cf. <20230801185232.1457172-1-jonathantanmy@google.com>\n>> source: \n>\n> I am happy with the most recent round, but I think that it is probably a\n> little late in the cycle to be merging down such a large change.\n>\n> I wouldn't be opposed if you did so, but it may be worth waiting until\n> we're on the other side of 2.42 so that other reviewers have a chance to\n\nSince I hear some folks (not just Google) base their own edition of\nGit on 'next', it probably is a good idea to merge it to 'next' and\nhave their users help find potential issues in it, as I agree that\nthe area it touches is important in the correctness department. Of\ncourse, it is important enough that the topic may very well want to\nbe cooked longer than the usual \"for at least one calendar week\" in\n'next', so I tend to agree that in a first few batches after the\nrelease may be the best time to have it graduate (if it turns out to\nbe OK).\n\nThanks.\n\n"},{"id":"480102","messageId":"ZMquQ7XiYKYNrc/e@nand.local","threadId":"60057","inReplyTo":"xmqqy1it6ykm.fsf@gitster.g","subject":"Re: jt/path-filter-fix","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2023-08-02T19:28:03Z","receivedAt":"2023-08-02T19:28:08Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Wed, Aug 02, 2023 at 12:20:25PM -0700, Junio C Hamano wrote:\n> Taylor Blau writes:\n>\n> > On Wed, Aug 02, 2023 at 11:10:34AM -0700, Junio C Hamano wrote:\n> >> * jt/path-filter-fix (2023-08-01) 7 commits\n> >> - commit-graph: new filter ver. that fixes murmur3\n> >> - repo-settings: introduce commitgraph.changedPathsVersion\n> >> - t4216: test changed path filters with high bit paths\n> >> - t/helper/test-read-graph: implement `bloom-filters` mode\n> >> - bloom.h: make `load_bloom_filter_from_graph()` public\n> >> - t/helper/test-read-graph.c: extract `dump_graph_info()`\n> >> - gitformat-commit-graph: describe version 2 of BDAT\n> >>\n> >> The Bloom filter used for path limited history traversal was broken\n> >> on systems whose \"char\" is unsigned; update the implementation and\n> >> bump the format version to 2.\n> >>\n> >> Still under discussion.\n> >> cf. <20230801185232.1457172-1-jonathantanmy@google.com>\n> >> source: \n> >\n> > I am happy with the most recent round, but I think that it is probably a\n> > little late in the cycle to be merging down such a large change.\n> >\n> > I wouldn't be opposed if you did so, but it may be worth waiting until\n> > we're on the other side of 2.42 so that other reviewers have a chance to\n>\n> Since I hear some folks (not just Google) base their own edition of\n> Git on 'next', it probably is a good idea to merge it to 'next' and\n> have their users help find potential issues in it, as I agree that\n> the area it touches is important in the correctness department. Of\n> course, it is important enough that the topic may very well want to\n> be cooked longer than the usual \"for at least one calendar week\" in\n> 'next', so I tend to agree that in a first few batches after the\n> release may be the best time to have it graduate (if it turns out to\n> be OK).\n\nYep, I agree with all of that. Thanks for juggling the merges, as always\n:-).\n\nThanks,\nTaylor\n"},{"id":"480211","messageId":"CAP8UFD2Fw+oGz4VK=_i3B_D_VMQqMoXTJPpXRbkDiWjHciEqJw@mail.gmail.com","threadId":"60057","inReplyTo":"CAP8UFD1vuB2kRr890B7GXum9HAMjRep86zy2tE4yE2C3W5QGHA@mail.gmail.com","subject":"Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2023-08-07T12:41:04Z","receivedAt":"2023-08-07T12:41:41Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"(Sorry I somehow forgot to put the mailing list in Cc: of this.)\n\nOn Fri, Aug 4, 2023 at 10:15 AM Christian Couder\n wrote:\n>\n> On Wed, Aug 2, 2023 at 10:55 PM Junio C Hamano wrote:\n>\n> > * cc/repack-sift-filtered-objects-to-separate-pack (2023-07-24) 8 commits\n> > . gc: add `gc.repackFilterTo` config option\n> > . repack: implement `--filter-to` for storing filtered out objects\n> > . gc: add `gc.repackFilter` config option\n> > . repack: add `--filter=` option\n> > . repack: refactor finding pack prefix\n> > . repack: refactor finishing pack-objects command\n> > . t/helper: add 'find-pack' test-tool\n> > . pack-objects: allow `--filter` without `--stdout`\n> >\n> > \"git repack\" machinery learns to pay attention to the \"--filter=\"\n> > option.\n> >\n> > Breaks CI with some environment variables configured.\n> > cf. \n> > source: <20230724085909.3831831-1-christian.couder@gmail.com>\n>\n> I am working on this and hope to send a version 4 soon.\n>\n> > * cc/git-replay (2023-06-03) 15 commits\n> > - replay: stop assuming replayed branches do not diverge\n> > - replay: add --contained to rebase contained branches\n> > - replay: add --advance or 'cherry-pick' mode\n> > - replay: disallow revision specific options and pathspecs\n> > - replay: use standard revision ranges\n> > - replay: make it a minimal server side command\n> > - replay: remove HEAD related sanity check\n> > - replay: remove progress and info output\n> > - replay: add an important FIXME comment about gpg signing\n> > - replay: don't simplify history\n> > - replay: introduce pick_regular_commit()\n> > - replay: die() instead of failing assert()\n> > - replay: start using parse_options API\n> > - replay: introduce new builtin\n> > - t6429: remove switching aspects of fast-rebase\n> >\n> > What's the status of this thing?\n> > source: <20230602102533.876905-1-christian.couder@gmail.com>\n>\n> I have a 2 week long vacation starting soon, so I will likely not have\n> time to work on a new round in the next 3 weeks.\n>\n> However in a recent article\n> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)\n> GitHub says that they are already using git-replay (though not sure\n> it's this exact version or another one), and GitLab plans to use it\n> too. So I guess it's worth keeping.\n"},{"id":"480218","messageId":"xmqqv8dqhlkz.fsf@gitster.g","threadId":"60057","inReplyTo":"CAP8UFD2Fw+oGz4VK=_i3B_D_VMQqMoXTJPpXRbkDiWjHciEqJw@mail.gmail.com","subject":"Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-08-07T16:19:08Z","receivedAt":"2023-08-07T16:19:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Couder writes:\n\n> (Sorry I somehow forgot to put the mailing list in Cc: of this.)\n\nThis seems to be a response to an older issue of the report, but I\ntake it that the status of these two topics haven't changed since\nthen.\n\n>> > * cc/repack-sift-filtered-objects-to-separate-pack (2023-07-24) 8 commits\n>> > ...\n>> > Breaks CI with some environment variables configured.\n>> > cf. \n>> > source: <20230724085909.3831831-1-christian.couder@gmail.com>\n>>\n>> I am working on this and hope to send a version 4 soon.\n\nSounds good. Thanks.\n\n>> > * cc/git-replay (2023-06-03) 15 commits\n>> > ...\n>> >\n>> > What's the status of this thing?\n>> > source: <20230602102533.876905-1-christian.couder@gmail.com>\n>>\n>> I have a 2 week long vacation starting soon, so I will likely not have\n>> time to work on a new round in the next 3 weeks.\n\nOK. Enjoy.\n\n>> However in a recent article\n>> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)\n>> GitHub says that they are already using git-replay (though not sure\n>> it's this exact version or another one), and GitLab plans to use it\n>> too.\n\nSo there are plenty folks who are capable of reviewing but they are\nnot interested in giving it to the general public by withholding\ntheir reviews ;-)?\n\n\n"},{"id":"480219","messageId":"ZNEaVefeE86s2V6h@nand.local","threadId":"60057","inReplyTo":"xmqqv8dqhlkz.fsf@gitster.g","subject":"Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2023-08-07T16:22:45Z","receivedAt":"2023-08-07T16:23:52Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Mon, Aug 07, 2023 at 09:19:08AM -0700, Junio C Hamano wrote:\n> >> However in a recent article\n> >> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)\n> >> GitHub says that they are already using git-replay (though not sure\n> >> it's this exact version or another one), and GitLab plans to use it\n> >> too.\n>\n> So there are plenty folks who are capable of reviewing but they are\n> not interested in giving it to the general public by withholding\n> their reviews ;-)?\n\nI think the most capable reviewer would be Johannes, who was most\ninvolved the Git-related parts of this work at GitHub.\n\nI was party to most of the changes that went through in this area, but\ndidn't look closely.\n\nThanks,\nTaylor\n"},{"id":"480228","messageId":"CABPp-BE5h6C1iuGDz4HdJzb2bDLidEnQ0_U4fv93JrYXA2_cbw@mail.gmail.com","threadId":"60057","inReplyTo":"xmqqv8dqhlkz.fsf@gitster.g","subject":"Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2023-08-07T16:56:12Z","receivedAt":"2023-08-07T16:56:56Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Aug 7, 2023 at 9:19 AM Junio C Hamano wrote:\n>\n[...]\n> >> However in a recent article\n> >> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)\n> >> GitHub says that they are already using git-replay (though not sure\n> >> it's this exact version or another one), and GitLab plans to use it\n> >> too.\n>\n> So there are plenty folks who are capable of reviewing but they are\n> not interested in giving it to the general public by withholding\n> their reviews ;-)?\n\nI can see how one could jump to that conclusion, but I don't think\nit's warranted. I have a little information that might shed some\nlight:\n\n-----\n\nAt the beginning of July, well before the above link came out,\nJohannes sent me an email pointing me at\nhttps://github.blog/changelog/2023-06-28-rebase-commits-now-created-using-the-merge-ort-strategy/.\nIn the email, he also noted my earlier stated concerns on the list\n(about releasing `replay` early possibly painting us into a corner\npreventing some desired goals for the tool from being realized), and\ntried to ensure we could still work towards having a `replay` command\nlike the one I envisioned while also asking for my thoughts on pushing\nfor the current portion of work to be published and included in git.\nMy sense was he was pushing for the work to be released, but just\nbeing careful about my concerns first.\n\nUnfortunately, I was on vacation that week, and sadly have otherwise\nbeen buried in coming up to speed on a new team and haven't had time\nto even respond to git-related stuff. I didn't respond to him until\nlate last week.\n\nI pointed out that the 'EXPERIMENTAL' banner addresses most of my\nconcerns so it should be fine to move forward, but I suspect my delay\nhas resulted in him now being buried in other matters, and in the\nmean-time the article Christian highlighted was produced by others.\n\n-----\n\nAnyway, hope that helps. I did review V2 and have been meaning to\ncomment on V3 (and respond to Toon's comments), though not sure my\n\"review\" counts as such since I'm the original author of most of the\npatches...\n\n(And sorry for being missing in action. I've flagged a few other\nemails that I'm hoping I can follow up on, but my time is currently\nquite limited...)\n"},{"id":"480260","messageId":"870d6901-e1ea-98fb-96fc-fd568bd35f16@gmail.com","threadId":"60057","inReplyTo":"xmqqfs518gdh.fsf@gitster.g","subject":"Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Rubén Justo","fromEmail":"rjusto@gmail.com","sentAt":"2023-08-07T20:59:07Z","receivedAt":"2023-08-07T21:00:19Z","isPatch":false,"sender":{"key":"rjusto@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5685487?v=4"},"body":"On 2/8/23 20:10, Junio C Hamano wrote:\n\n> * rj/status-bisect-while-rebase (2023-08-01) 1 commit\n> - status: fix branch shown when not only bisecting\n> \n> \"git status\" is taught to show both the branch being bisected and\n> being rebased when both are in effect at the same time.\n\nMaybe this suggest that something has been added, but only fixed.\n\nPerhaps we can say something like:\n\n \"git status\" was not showing accurate information when bisect and\n other operation are in effect at the same time.\n\n> \n> Needs review.\n> source: <48745298-f12b-8efb-4e48-90d2c22a8349@gmail.com>\n\nThanks.\n"},{"id":"480324","messageId":"20230808192240.GA4091261@coredump.intra.peff.net","threadId":"60057","inReplyTo":"xmqqfs518gdh.fsf@gitster.g","subject":"leak in jt/path-filter-fix, was Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-08-08T19:22:40Z","receivedAt":"2023-08-08T20:18:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 02, 2023 at 11:10:34AM -0700, Junio C Hamano wrote:\n\n> * jt/path-filter-fix (2023-08-01) 7 commits\n> - commit-graph: new filter ver. that fixes murmur3\n> - repo-settings: introduce commitgraph.changedPathsVersion\n> - t4216: test changed path filters with high bit paths\n> - t/helper/test-read-graph: implement `bloom-filters` mode\n> - bloom.h: make `load_bloom_filter_from_graph()` public\n> - t/helper/test-read-graph.c: extract `dump_graph_info()`\n> - gitformat-commit-graph: describe version 2 of BDAT\n> \n> The Bloom filter used for path limited history traversal was broken\n> on systems whose \"char\" is unsigned; update the implementation and\n> bump the format version to 2.\n> \n> Still under discussion.\n> cf. <20230801185232.1457172-1-jonathantanmy@google.com>\n> source: \n\nSince this hit 'next', Coverity complained about a small leak. Fixed by\nthe patch below.\n\n-- >8 --\nSubject: [PATCH] commit-graph: fix small leak with invalid changedPathsVersion\n\nWhen writing a commit graph, we sanity-check the value of\ncommitgraph.changedPathsVersion and return early if it's invalid. But we\nonly do so after allocating the write_commit_graph_context, meaing we\nleak it. We could \"goto cleanup\" to fix this, but instead let's push\nthis check to the top of the function with the other early checks which\nreturn before doing any work.\n\nSigned-off-by: Jeff King \n---\n commit-graph.c | 12 ++++++------\n 1 file changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/commit-graph.c b/commit-graph.c\nindex 38edb12669..ccc21c6708 100644\n--- a/commit-graph.c\n+++ b/commit-graph.c\n@@ -2372,6 +2372,12 @@ int write_commit_graph(struct object_directory *odb,\n \t}\n \tif (!commit_graph_compatible(r))\n \t\treturn 0;\n+\tif (r->settings.commit_graph_changed_paths_version < -1\n+\t || r->settings.commit_graph_changed_paths_version > 2) {\n+\t\twarning(_(\"attempting to write a commit-graph, but 'commitgraph.changedPathsVersion' (%d) is not supported\"),\n+\t\t\tr->settings.commit_graph_changed_paths_version);\n+\t\treturn 0;\n+\t}\n \n \tCALLOC_ARRAY(ctx, 1);\n \tctx->r = r;\n@@ -2384,12 +2390,6 @@ int write_commit_graph(struct object_directory *odb,\n \tctx->write_generation_data = (get_configured_generation_version(r) == 2);\n \tctx->num_generation_data_overflows = 0;\n \n-\tif (r->settings.commit_graph_changed_paths_version < -1\n-\t || r->settings.commit_graph_changed_paths_version > 2) {\n-\t\twarning(_(\"attempting to write a commit-graph, but 'commitgraph.changedPathsVersion' (%d) is not supported\"),\n-\t\t\tr->settings.commit_graph_changed_paths_version);\n-\t\treturn 0;\n-\t}\n \tbloom_settings.hash_version = r->settings.commit_graph_changed_paths_version == 2\n \t\t? 2 : 1;\n \tbloom_settings.bits_per_entry = git_env_ulong(\"GIT_TEST_BLOOM_SETTINGS_BITS_PER_ENTRY\",\n-- \n2.42.0.rc0.376.g66bfc4f195\n\n"},{"id":"480325","messageId":"20230808192540.GA319679@coredump.intra.peff.net","threadId":"60057","inReplyTo":"20230808192240.GA4091261@coredump.intra.peff.net","subject":"Re: leak in jt/path-filter-fix, was Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-08-08T19:25:40Z","receivedAt":"2023-08-08T20:20:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 08, 2023 at 03:22:41PM -0400, Jeff King wrote:\n\n> Subject: [PATCH] commit-graph: fix small leak with invalid changedPathsVersion\n> \n> When writing a commit graph, we sanity-check the value of\n> commitgraph.changedPathsVersion and return early if it's invalid. But we\n> only do so after allocating the write_commit_graph_context, meaing we\n> leak it. We could \"goto cleanup\" to fix this, but instead let's push\n> this check to the top of the function with the other early checks which\n> return before doing any work.\n\nI am tempted to do this on top, but maybe it is just churn. I dunno.\n\n-- >8 --\nSubject: [PATCH] commit-graph: store write context on stack rather than heap\n\nIn write_commit_graph(), we allocate our context struct on the heap.\nBut there's no reason to do so, since it's small and we always free it\nwhen exiting the function. Converting it to a stack variable is slightly\nmore efficient, but also can prevent some leaks (such as the one fixed\nin the previous commit, though to be fair this only helps for such a\nlimited leak; once any sub-fields of the struct require allocation, it\nhas to be cleaned up).\n\nSigned-off-by: Jeff King \n---\n commit-graph.c | 140 ++++++++++++++++++++++++-------------------------\n 1 file changed, 69 insertions(+), 71 deletions(-)\n\ndiff --git a/commit-graph.c b/commit-graph.c\nindex ccc21c6708..b8db056f37 100644\n--- a/commit-graph.c\n+++ b/commit-graph.c\n@@ -2358,7 +2358,7 @@ int write_commit_graph(struct object_directory *odb,\n \t\t const struct commit_graph_opts *opts)\n {\n \tstruct repository *r = the_repository;\n-\tstruct write_commit_graph_context *ctx;\n+\tstruct write_commit_graph_context ctx;\n \tuint32_t i;\n \tint res = 0;\n \tint replace = 0;\n@@ -2379,16 +2379,16 @@ int write_commit_graph(struct object_directory *odb,\n \t\treturn 0;\n \t}\n \n-\tCALLOC_ARRAY(ctx, 1);\n-\tctx->r = r;\n-\tctx->odb = odb;\n-\tctx->append = flags & COMMIT_GRAPH_WRITE_APPEND ? 1 : 0;\n-\tctx->report_progress = flags & COMMIT_GRAPH_WRITE_PROGRESS ? 1 : 0;\n-\tctx->split = flags & COMMIT_GRAPH_WRITE_SPLIT ? 1 : 0;\n-\tctx->opts = opts;\n-\tctx->total_bloom_filter_data_size = 0;\n-\tctx->write_generation_data = (get_configured_generation_version(r) == 2);\n-\tctx->num_generation_data_overflows = 0;\n+\tmemset(&ctx, 0, sizeof(ctx));\n+\tctx.r = r;\n+\tctx.odb = odb;\n+\tctx.append = flags & COMMIT_GRAPH_WRITE_APPEND ? 1 : 0;\n+\tctx.report_progress = flags & COMMIT_GRAPH_WRITE_PROGRESS ? 1 : 0;\n+\tctx.split = flags & COMMIT_GRAPH_WRITE_SPLIT ? 1 : 0;\n+\tctx.opts = opts;\n+\tctx.total_bloom_filter_data_size = 0;\n+\tctx.write_generation_data = (get_configured_generation_version(r) == 2);\n+\tctx.num_generation_data_overflows = 0;\n \n \tbloom_settings.hash_version = r->settings.commit_graph_changed_paths_version == 2\n \t\t? 2 : 1;\n@@ -2398,14 +2398,14 @@ int write_commit_graph(struct object_directory *odb,\n \t\t\t\t\t\t bloom_settings.num_hashes);\n \tbloom_settings.max_changed_paths = git_env_ulong(\"GIT_TEST_BLOOM_SETTINGS_MAX_CHANGED_PATHS\",\n \t\t\t\t\t\t\t bloom_settings.max_changed_paths);\n-\tctx->bloom_settings = &bloom_settings;\n+\tctx.bloom_settings = &bloom_settings;\n \n \tinit_topo_level_slab(&topo_levels);\n-\tctx->topo_levels = &topo_levels;\n+\tctx.topo_levels = &topo_levels;\n \n-\tprepare_commit_graph(ctx->r);\n-\tif (ctx->r->objects->commit_graph) {\n-\t\tstruct commit_graph *g = ctx->r->objects->commit_graph;\n+\tprepare_commit_graph(ctx.r);\n+\tif (ctx.r->objects->commit_graph) {\n+\t\tstruct commit_graph *g = ctx.r->objects->commit_graph;\n \n \t\twhile (g) {\n \t\t\tg->topo_levels = &topo_levels;\n@@ -2414,128 +2414,126 @@ int write_commit_graph(struct object_directory *odb,\n \t}\n \n \tif (flags & COMMIT_GRAPH_WRITE_BLOOM_FILTERS)\n-\t\tctx->changed_paths = 1;\n+\t\tctx.changed_paths = 1;\n \tif (!(flags & COMMIT_GRAPH_NO_WRITE_BLOOM_FILTERS)) {\n \t\tstruct commit_graph *g;\n \n-\t\tg = ctx->r->objects->commit_graph;\n+\t\tg = ctx.r->objects->commit_graph;\n \n \t\t/* We have changed-paths already. Keep them in the next graph */\n \t\tif (g && g->bloom_filter_settings) {\n-\t\t\tctx->changed_paths = 1;\n-\t\t\tctx->bloom_settings = g->bloom_filter_settings;\n+\t\t\tctx.changed_paths = 1;\n+\t\t\tctx.bloom_settings = g->bloom_filter_settings;\n \t\t}\n \t}\n \n-\tif (ctx->split) {\n-\t\tstruct commit_graph *g = ctx->r->objects->commit_graph;\n+\tif (ctx.split) {\n+\t\tstruct commit_graph *g = ctx.r->objects->commit_graph;\n \n \t\twhile (g) {\n-\t\t\tctx->num_commit_graphs_before++;\n+\t\t\tctx.num_commit_graphs_before++;\n \t\t\tg = g->base_graph;\n \t\t}\n \n-\t\tif (ctx->num_commit_graphs_before) {\n-\t\t\tALLOC_ARRAY(ctx->commit_graph_filenames_before, ctx->num_commit_graphs_before);\n-\t\t\ti = ctx->num_commit_graphs_before;\n-\t\t\tg = ctx->r->objects->commit_graph;\n+\t\tif (ctx.num_commit_graphs_before) {\n+\t\t\tALLOC_ARRAY(ctx.commit_graph_filenames_before, ctx.num_commit_graphs_before);\n+\t\t\ti = ctx.num_commit_graphs_before;\n+\t\t\tg = ctx.r->objects->commit_graph;\n \n \t\t\twhile (g) {\n-\t\t\t\tctx->commit_graph_filenames_before[--i] = xstrdup(g->filename);\n+\t\t\t\tctx.commit_graph_filenames_before[--i] = xstrdup(g->filename);\n \t\t\t\tg = g->base_graph;\n \t\t\t}\n \t\t}\n \n-\t\tif (ctx->opts)\n-\t\t\treplace = ctx->opts->split_flags & COMMIT_GRAPH_SPLIT_REPLACE;\n+\t\tif (ctx.opts)\n+\t\t\treplace = ctx.opts->split_flags & COMMIT_GRAPH_SPLIT_REPLACE;\n \t}\n \n-\tctx->approx_nr_objects = repo_approximate_object_count(the_repository);\n+\tctx.approx_nr_objects = repo_approximate_object_count(the_repository);\n \n-\tif (ctx->append && ctx->r->objects->commit_graph) {\n-\t\tstruct commit_graph *g = ctx->r->objects->commit_graph;\n+\tif (ctx.append && ctx.r->objects->commit_graph) {\n+\t\tstruct commit_graph *g = ctx.r->objects->commit_graph;\n \t\tfor (i = 0; i < g->num_commits; i++) {\n \t\t\tstruct object_id oid;\n \t\t\toidread(&oid, g->chunk_oid_lookup + g->hash_len * i);\n-\t\t\toid_array_append(&ctx->oids, &oid);\n+\t\t\toid_array_append(&ctx.oids, &oid);\n \t\t}\n \t}\n \n \tif (pack_indexes) {\n-\t\tctx->order_by_pack = 1;\n-\t\tif ((res = fill_oids_from_packs(ctx, pack_indexes)))\n+\t\tctx.order_by_pack = 1;\n+\t\tif ((res = fill_oids_from_packs(&ctx, pack_indexes)))\n \t\t\tgoto cleanup;\n \t}\n \n \tif (commits) {\n-\t\tif ((res = fill_oids_from_commits(ctx, commits)))\n+\t\tif ((res = fill_oids_from_commits(&ctx, commits)))\n \t\t\tgoto cleanup;\n \t}\n \n \tif (!pack_indexes && !commits) {\n-\t\tctx->order_by_pack = 1;\n-\t\tfill_oids_from_all_packs(ctx);\n+\t\tctx.order_by_pack = 1;\n+\t\tfill_oids_from_all_packs(&ctx);\n \t}\n \n-\tclose_reachable(ctx);\n+\tclose_reachable(&ctx);\n \n-\tcopy_oids_to_commits(ctx);\n+\tcopy_oids_to_commits(&ctx);\n \n-\tif (ctx->commits.nr >= GRAPH_EDGE_LAST_MASK) {\n+\tif (ctx.commits.nr >= GRAPH_EDGE_LAST_MASK) {\n \t\terror(_(\"too many commits to write graph\"));\n \t\tres = -1;\n \t\tgoto cleanup;\n \t}\n \n-\tif (!ctx->commits.nr && !replace)\n+\tif (!ctx.commits.nr && !replace)\n \t\tgoto cleanup;\n \n-\tif (ctx->split) {\n-\t\tsplit_graph_merge_strategy(ctx);\n+\tif (ctx.split) {\n+\t\tsplit_graph_merge_strategy(&ctx);\n \n \t\tif (!replace)\n-\t\t\tmerge_commit_graphs(ctx);\n+\t\t\tmerge_commit_graphs(&ctx);\n \t} else\n-\t\tctx->num_commit_graphs_after = 1;\n+\t\tctx.num_commit_graphs_after = 1;\n \n-\tctx->trust_generation_numbers = validate_mixed_generation_chain(ctx->r->objects->commit_graph);\n+\tctx.trust_generation_numbers = validate_mixed_generation_chain(ctx.r->objects->commit_graph);\n \n-\tcompute_topological_levels(ctx);\n-\tif (ctx->write_generation_data)\n-\t\tcompute_generation_numbers(ctx);\n+\tcompute_topological_levels(&ctx);\n+\tif (ctx.write_generation_data)\n+\t\tcompute_generation_numbers(&ctx);\n \n-\tif (ctx->changed_paths)\n-\t\tcompute_bloom_filters(ctx);\n+\tif (ctx.changed_paths)\n+\t\tcompute_bloom_filters(&ctx);\n \n-\tres = write_commit_graph_file(ctx);\n+\tres = write_commit_graph_file(&ctx);\n \n-\tif (ctx->split)\n-\t\tmark_commit_graphs(ctx);\n+\tif (ctx.split)\n+\t\tmark_commit_graphs(&ctx);\n \n-\texpire_commit_graphs(ctx);\n+\texpire_commit_graphs(&ctx);\n \n cleanup:\n-\tfree(ctx->graph_name);\n-\tfree(ctx->commits.list);\n-\toid_array_clear(&ctx->oids);\n+\tfree(ctx.graph_name);\n+\tfree(ctx.commits.list);\n+\toid_array_clear(&ctx.oids);\n \tclear_topo_level_slab(&topo_levels);\n \n-\tif (ctx->commit_graph_filenames_after) {\n-\t\tfor (i = 0; i < ctx->num_commit_graphs_after; i++) {\n-\t\t\tfree(ctx->commit_graph_filenames_after[i]);\n-\t\t\tfree(ctx->commit_graph_hash_after[i]);\n+\tif (ctx.commit_graph_filenames_after) {\n+\t\tfor (i = 0; i < ctx.num_commit_graphs_after; i++) {\n+\t\t\tfree(ctx.commit_graph_filenames_after[i]);\n+\t\t\tfree(ctx.commit_graph_hash_after[i]);\n \t\t}\n \n-\t\tfor (i = 0; i < ctx->num_commit_graphs_before; i++)\n-\t\t\tfree(ctx->commit_graph_filenames_before[i]);\n+\t\tfor (i = 0; i < ctx.num_commit_graphs_before; i++)\n+\t\t\tfree(ctx.commit_graph_filenames_before[i]);\n \n-\t\tfree(ctx->commit_graph_filenames_after);\n-\t\tfree(ctx->commit_graph_filenames_before);\n-\t\tfree(ctx->commit_graph_hash_after);\n+\t\tfree(ctx.commit_graph_filenames_after);\n+\t\tfree(ctx.commit_graph_filenames_before);\n+\t\tfree(ctx.commit_graph_hash_after);\n \t}\n \n-\tfree(ctx);\n-\n \treturn res;\n }\n \n-- \n2.42.0.rc0.376.g66bfc4f195\n\n"},{"id":"480336","messageId":"ZNKj9vwZv4kKJEcL@nand.local","threadId":"60057","inReplyTo":"20230808192240.GA4091261@coredump.intra.peff.net","subject":"Re: leak in jt/path-filter-fix, was Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2023-08-08T20:22:14Z","receivedAt":"2023-08-08T21:10:03Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, Aug 08, 2023 at 03:22:40PM -0400, Jeff King wrote:\n> Since this hit 'next', Coverity complained about a small leak. Fixed by\n> the patch below.\n\nThe patch below looks good and makes sense to me. That warning is\nawfully long, though ;-).\n\nIn any event, I expect that 'next' will be rewound before this topic\ngraduates, since it is meaty and we are in the middle of the -rc phase.\n\n...and we also have my series on top [1], so it may be worthwhile for\nyou, Jonathan, and I to figure out how to combine our efforts here. I\nthink that this could likely get squashed in to Jonathan's topic\nif/after it gets ejected from 'next'. We can take my patches together in\nthe same series, separately in a different one, or discard them\naltogether.\n\nIf we do decide to pursue the approach in [1], I think combining\neverything together into one big series makes the most sense for ease of\nmerging.\n\n[1]: https://lore.kernel.org/git/ZMv14grkM7x7Sf8m@nand.local/\n\nThanks,\nTaylor\n"},{"id":"480339","messageId":"20230808211957.GB322409@coredump.intra.peff.net","threadId":"60057","inReplyTo":"ZNKj9vwZv4kKJEcL@nand.local","subject":"Re: leak in jt/path-filter-fix, was Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-08-08T21:19:57Z","receivedAt":"2023-08-08T21:22:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 08, 2023 at 04:22:14PM -0400, Taylor Blau wrote:\n\n> On Tue, Aug 08, 2023 at 03:22:40PM -0400, Jeff King wrote:\n> > Since this hit 'next', Coverity complained about a small leak. Fixed by\n> > the patch below.\n> \n> The patch below looks good and makes sense to me. That warning is\n> awfully long, though ;-).\n> \n> In any event, I expect that 'next' will be rewound before this topic\n> graduates, since it is meaty and we are in the middle of the -rc phase.\n> \n> ...and we also have my series on top [1], so it may be worthwhile for\n> you, Jonathan, and I to figure out how to combine our efforts here. I\n> think that this could likely get squashed in to Jonathan's topic\n> if/after it gets ejected from 'next'. We can take my patches together in\n> the same series, separately in a different one, or discard them\n> altogether.\n> \n> If we do decide to pursue the approach in [1], I think combining\n> everything together into one big series makes the most sense for ease of\n> merging.\n\nYeah, I am just coming back from vacation and didn't follow all of the\ndiscussion on this topic carefully. The few patches I sent today were\njust enough to get the test suite passing again (the send-email fixes)\nand silence any new Coverity warnings. ;)\n\nIf it does get re-rolled, I would be quite happy if my fix here just\ngets squashed into the appropriate commit.\n\n-Peff\n"},{"id":"480603","messageId":"20230811221541.3332720-1-jonathantanmy@google.com","threadId":"60057","inReplyTo":"ZNKj9vwZv4kKJEcL@nand.local","subject":"Re: leak in jt/path-filter-fix, was Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Jonathan Tan","fromEmail":"jonathantanmy@google.com","sentAt":"2023-08-11T22:15:41Z","receivedAt":"2023-08-11T22:15:47Z","isPatch":false,"sender":{"key":"jonathantanmy@fastmail.com","avatar":null},"body":"Taylor Blau writes:\n> On Tue, Aug 08, 2023 at 03:22:40PM -0400, Jeff King wrote:\n> > Since this hit 'next', Coverity complained about a small leak. Fixed by\n> > the patch below.\n> \n> The patch below looks good and makes sense to me. That warning is\n> awfully long, though ;-).\n> \n> In any event, I expect that 'next' will be rewound before this topic\n> graduates, since it is meaty and we are in the middle of the -rc phase.\n> \n> ...and we also have my series on top [1], so it may be worthwhile for\n> you, Jonathan, and I to figure out how to combine our efforts here. I\n> think that this could likely get squashed in to Jonathan's topic\n> if/after it gets ejected from 'next'. We can take my patches together in\n> the same series, separately in a different one, or discard them\n> altogether.\n> \n> If we do decide to pursue the approach in [1], I think combining\n> everything together into one big series makes the most sense for ease of\n> merging.\n> \n> [1]: https://lore.kernel.org/git/ZMv14grkM7x7Sf8m@nand.local/\n> \n> Thanks,\n> Taylor\n\nFor what it's worth, whatever we decide sounds good to me.\n"},{"id":"480748","messageId":"304f2a49-5e05-7655-9f87-2011606df5db@gmx.de","threadId":"60057","inReplyTo":"CABPp-BE5h6C1iuGDz4HdJzb2bDLidEnQ0_U4fv93JrYXA2_cbw@mail.gmail.com","subject":"Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2023-08-17T13:21:59Z","receivedAt":"2023-08-17T13:23:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 7 Aug 2023, Elijah Newren wrote:\n\n> On Mon, Aug 7, 2023 at 9:19 AM Junio C Hamano wrote:\n> >\n> [...]\n> > >> However in a recent article\n> > >> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)\n> > >> GitHub says that they are already using git-replay (though not sure\n> > >> it's this exact version or another one), and GitLab plans to use it\n> > >> too.\n> >\n> > So there are plenty folks who are capable of reviewing but they are\n> > not interested in giving it to the general public by withholding\n> > their reviews ;-)?\n>\n> I can see how one could jump to that conclusion, but I don't think\n> it's warranted. I have a little information that might shed some\n> light:\n>\n> -----\n>\n> At the beginning of July, well before the above link came out,\n> Johannes sent me an email pointing me at\n> https://github.blog/changelog/2023-06-28-rebase-commits-now-created-using-the-merge-ort-strategy/.\n> In the email, he also noted my earlier stated concerns on the list\n> (about releasing `replay` early possibly painting us into a corner\n> preventing some desired goals for the tool from being realized), and\n> tried to ensure we could still work towards having a `replay` command\n> like the one I envisioned while also asking for my thoughts on pushing\n> for the current portion of work to be published and included in git.\n> My sense was he was pushing for the work to be released, but just\n> being careful about my concerns first.\n\nIndeed. The patches that are running on GitHub to support rebases\nincorporate v3 of the `git-replay` patch series, and add a couple of\npatches on top to perform rebases similar to how things were done using\nlibgit2 before.\n\n> Unfortunately, I was on vacation that week, and sadly have otherwise\n> been buried in coming up to speed on a new team and haven't had time\n> to even respond to git-related stuff. I didn't respond to him until\n> late last week.\n>\n> I pointed out that the 'EXPERIMENTAL' banner addresses most of my\n> concerns so it should be fine to move forward, but I suspect my delay\n> has resulted in him now being buried in other matters, and in the\n> mean-time the article Christian highlighted was produced by others.\n\nThe article was produced with my input, so I cannot claim innocence.\n\nThe reason why I did not respond earlier is that I wanted to have more\ntime to push forward with your vision of `git replay`, in a direction\nwhere it avoids repeating the design of `git rebase`.\n\nAbout integrating the current patch series as-is, I would be fine with it.\nThe best support I can offer is that this code (with minor changes that do\nnot fundamentally modify how the core logic works) has performed\ngazillions of rebases in the meantime.\n\nWe just need to be mindful to keep that EXPERIMENTAL label until we fully\nimplement the design Elijah envisions. Which might very well need the user\ninterface to change rather drastically.\n\n> Anyway, hope that helps. I did review V2 and have been meaning to\n> comment on V3 (and respond to Toon's comments), though not sure my\n> \"review\" counts as such since I'm the original author of most of the\n> patches...\n>\n> (And sorry for being missing in action. I've flagged a few other\n> emails that I'm hoping I can follow up on, but my time is currently\n> quite limited...)\n\nI haven't been a frequent guest on the Git mailing list, either, lately...\n\nCiao,\nJohannes\n"}]}