threads / discuss / 60057

What's cooking in git.git (Aug 2023, #01; Wed, 2)

Subject: What's cooking in git.git (Aug 2023, #01; Wed, 2)

## tl;dr

15 messages between Aug 2, 2023 and Aug 17, 2023.

replies: 14people: 8as markdown or json

Junio C Hamano· Aug 2, 2023, 18:10 UTC · lore

Here are the topics that have been cooking in my tree. Commits prefixed with '+' are in 'next' (being in 'next' is a sign that a topic is stable enough to be used and are candidate to be in a future release). Commits prefixed with '-' are only in 'seen', and aren't considered "accepted" at all and may be annotated with an URL to a message that raises issues but they are no means exhaustive. A topic without enough support may be discarded after a long period of no activity (of course they can be resubmit when new interests arise).

We are getting closer to the final phase of this cycle, which begins when -rc0 preview release is tagged this coming Friday, followed by about 1 1/2 weeks of stabilization period that begins when -rc1 is tagged (cf. tinyurl.com/gitCal). There are a handful of topics that still need reviews before getting merged to 'next', but because the summer in the northern hemisphere is historically a slower season, too few reviewers seem to be active, relative to the number of these topics.

Copies of the source code to Git live in many repositories, and the following is a list of the ones I push into or their mirrors. Some repositories have only a subset of branches.

With maint, master, next, seen, todo:
	git://git.kernel.org/pub/scm/git/git.git/
	git://repo.or.cz/alt-git.git/
	https://kernel.googlesource.com/pub/scm/git/git/
	https://github.com/git/git/
	https://gitlab.com/git-vcs/git/
With all the integration branches and topics broken out:
	https://github.com/gitster/git/

Even though the preformatted documentation in HTML and man format are not sources, they are published in these repositories for convenience (replace "htmldocs" with "manpages" for the manual pages):

	git://git.kernel.org/pub/scm/git/git-htmldocs.git/
	https://github.com/gitster/git-htmldocs.git/
Release tarballs are available at:
	https://www.kernel.org/pub/software/scm/git/

-------------------------------------------------- [Graduated to 'master']

* ah/autoconf-fixes (2023-07-19) 3 commits
  (merged to 'next' on 2023-07-25 at 35ff66e0cb)
 + configure.ac: always save NO_ICONV to config.status
 + configure.ac: don't overwrite NO_CURL option
 + configure.ac: don't overwrite NO_EXPAT option
 "./configure --with-expat=no" did not work as a way to refuse use
 of the expat library on a system with the library installed, which
 has been corrected.
 source: <20230719145211.17854-2-aherrmann@suse.de>
* ah/sequencer-rewrite-todo-fix (2023-07-24) 1 commit
  (merged to 'next' on 2023-07-26 at 24e74d9eda)
 + sequencer: finish parsing the todo list despite an invalid first line
 When the user edits "rebase -i" todo file so that it starts with a
 "fixup", which would make it invalid, the command truncated the
 rest of the file before giving an error and returning the control
 back to the user.  Stop truncating to make it easier to correct
 such a malformed todo file.
 cf. <https://lore.kernel.org/git/0d1c5bfd-3ae5-83f0-a333-bbb8510a973a@gmail.com/>
 source: <20230722212830.132135-2-alexhenrie24@gmail.com>
* bb/use-trace2-counters-for-fsync-stats (2023-07-20) 1 commit
  (merged to 'next' on 2023-07-26 at f2c2e3f2b9)
 + wrapper: use trace2 counters to collect fsync stats
 Instead of inventing a custom counter variables for debugging,
 use existing trace2 facility in the fsync customization codepath.
 source: <20230720164823.625815-1-dev+git@drbeat.li>
* jc/tree-walk-drop-base-offset (2023-07-07) 2 commits
  (merged to 'next' on 2023-07-25 at cc050c60a6)
 + tree-walk: drop unused base_offset from do_match()
 + tree-walk: lose base_offset that is never used in tree_entry_interesting
 Code simplification.
 source: <20230707222116.4129415-1-gitster@pobox.com>
* ks/ref-filter-describe (2023-07-24) 2 commits
  (merged to 'next' on 2023-07-26 at f4b3b3b7ef)
 + ref-filter: add new "describe" atom
 + ref-filter: add multiple-option parsing functions
 "git branch --list --format=<format>" and friends are taught
 a new "%(describe)" placeholder.
 source: <20230723162717.68123-1-five231003@gmail.com>

-------------------------------------------------- [New Topics]

* bc/ident-dot-is-no-longer-crud-letter (2023-08-02) 1 commit
 - ident: don't consider '.' a crud
 Exclude "." from the set of characters to be removed from the
 beginning and the end of the human-readable name.
 Will merge to 'next'?
 source: <xmqqsf918k4j.fsf@gitster.g>
* jc/unresolve-removal (2023-07-31) 7 commits
 - checkout: allow "checkout -m path" to unmerge removed paths
 - checkout/restore: add basic tests for --merge
 - checkout/restore: refuse unmerging paths unless checking out of the index
 - update-index: remove stale fallback code for "--unresolve"
 - update-index: use unmerge_index_entry() to support removal
 - resolve-undo: allow resurrecting conflicted state that resolved to deletion
 - update-index: do not read HEAD and MERGE_HEAD unconditionally
 "checkout --merge -- path" and "update-index --unresolve path" did
 not resurrect conflicted state that was resolved to remove path,
 but now they do.
 Needs review.
 source: <20230731224409.4181277-1-gitster@pobox.com>
* ew/hash-with-openssl-evp (2023-08-01) 2 commits
 - avoid SHA-1 functions deprecated in OpenSSL 3+
 - sha256: avoid functions deprecated in OpenSSL 3+
 Adjust to OpenSSL 3+, which deprecates its SHA-1 functions based on
 its traditional API, by using its EVP API instead.
 Will merge to 'next'. 
 source: <20230801025454.1137802-1-e@80x24.org>
* rj/status-bisect-while-rebase (2023-08-01) 1 commit
 - status: fix branch shown when not only bisecting
 "git status" is taught to show both the branch being bisected and
 being rebased when both are in effect at the same time.
 Needs review.
 source: <48745298-f12b-8efb-4e48-90d2c22a8349@gmail.com>

-------------------------------------------------- [Stalled]

* tk/cherry-pick-sequence-requires-clean-worktree (2023-06-01) 1 commit
 - cherry-pick: refuse cherry-pick sequence if index is dirty
 "git cherry-pick A" that replays a single commit stopped before
 clobbering local modification, but "git cherry-pick A..B" did not,
 which has been corrected.
 Expecting a reroll.
 cf. <999f12b2-38d6-f446-e763-4985116ad37d@gmail.com>
 source: <pull.1535.v2.git.1685264889088.gitgitgadget@gmail.com>
* ab/tag-object-type-errors (2023-05-10) 4 commits
 - tag: don't emit potentially incorrect "object is a X, not a Y"
 - tag: don't misreport type of tagged objects in errors
 - object tests: add test for unexpected objects in tags
 - Merge branch 'jk/parse-object-type-mismatch' into ab/tag-object-type-errors
 Hardening checks around mismatched object types when one of those
 objects is a tag.
 Will discard.
 Stalled for too long.
 source: <cover-v2-0.3-00000000000-20221230T011725Z-avarab@gmail.com>
* ob/revert-of-revert (2023-05-05) 1 commit
 - sequencer: beautify subject of reverts of reverts
 Instead of "Revert "Revert "original"", give "Reapply "original""
 as the title for a revert of a revert.
 Will discard.
 Have been expecting a hopefully final reroll for too long.
 Looking much better, except for minor cosmetic issues.
 cf. <xmqqmt21txid.fsf@gitster.g>
 source: <20230428083528.1699221-1-oswald.buddenhagen@gmx.de>
* pw/rebase-i-after-failure (2023-08-01) 7 commits
 - rebase -i: fix adding failed command to the todo list
 - rebase --continue: refuse to commit after failed command
 - rebase: fix rewritten list for failed pick
 - sequencer: factor out part of pick_commits()
 - sequencer: use rebase_path_message()
 - rebase -i: remove patch file after conflict resolution
 - rebase -i: move unlink() calls
 Various fixes to the behaviour of "rebase -i" when the command got
 interrupted by conflicting changes.
 Will merge to 'next'?
 cf. <xmqqa5vad6ea.fsf@gitster.g>
 cf. <xmqq5y5yd6d7.fsf@gitster.g>
 source: <pull.1492.v3.git.1690903412.gitgitgadget@gmail.com>

-------------------------------------------------- [Cooking]

* ew/sha256-gcrypt-leak-fixes (2023-07-31) 3 commits
  (merged to 'next' on 2023-08-01 at eed83801c3)
 + sha256/gcrypt: die on gcry_md_open failures
 + sha256/gcrypt: fix memory leak with SHA-256 repos
 + sha256/gcrypt: fix build with SANITIZE=leak
 Leakfixes.
 Will merge to 'master'.
 source: <20230731120808.1230210-1-e@80x24.org>
* rs/bundle-parseopt-cleanup (2023-07-31) 1 commit
  (merged to 'next' on 2023-08-01 at 405eb138fa)
 + bundle: use OPT_PASSTHRU_ARGV
 Code clean-up.
 Will merge to 'master'.
 source: <2dcb915f-b926-e024-6394-23aff200955c@web.de>
* pv/doc-submodule-update-settings (2023-07-25) 1 commit
  (merged to 'next' on 2023-07-27 at e27b5b7ba8)
 + doc: highlight that .gitmodules does not support !command
 Rewrite the description of giving a custom command to the
 submodule.<name>.update configuraiton variable.
 Will merge to 'master'.
 source: <20230725212218.711116-1-pvutov@imap.cc>
* la/doc-choose-starting-point-fixup (2023-07-27) 3 commits
  (merged to 'next' on 2023-07-28 at 047dcae31c)
 + SubmittingPatches: use of older maintenance tracks is an exception
 + SubmittingPatches: explain why 'next' and above are inappropriate base
 + SubmittingPatches: choice of base for fixing an older maintenance track
 (this branch uses la/doc-choose-starting-point.)
 Clarify how to pick a starting point for a new topic in the
 SubmittingPatches document.
 Will merge to 'master', together with the underlying topic.
 source: <pull.1556.v2.git.1689314493.gitgitgadget@gmail.com>
 source: <pull.1556.v3.git.1690340701.gitgitgadget@gmail.com>
* am/doc-sha256 (2023-07-31) 1 commit
  (merged to 'next' on 2023-08-01 at d7419bf527)
 + doc: sha256 is no longer experimental
 Tone down the warning on SHA-256 repositories being an experimental
 curiosity.  We do not have support for them to interoperate with
 traditional SHA-1 repositories, but at this point, we do not plan
 to make breaking changes to SHA-256 repositories and there is no
 longer need for such a strongly phrased warning.
 Will merge to 'master'.
 source: <ZMe6KmzZGVubYpvO@adams>
* hy/blame-in-bare-with-contents (2023-07-21) 1 commit
  (merged to 'next' on 2023-07-31 at 39ac96d8d8)
 + blame: allow --contents to work with bare repo
 "git blame --contents=file" has been taught to work in a bare
 repository.
 Will merge to 'master'.
 source: <20230721035758.61956-1-hanyang.tony@bytedance.com>
* ja/worktree-orphan-fix (2023-07-26) 3 commits
  (merged to 'next' on 2023-07-27 at e475016065)
 + t2400: rewrite regex to avoid unintentional PCRE
 + builtin/worktree.c: convert tab in advice to space
 + t2400: drop no-op `--sq` from rev-parse call
 Fix tests with unportable regex patterns.
 Will merge to 'master'.
 source: <20230726214202.15775-1-jacobabel@nullpo.dev>
* jc/retire-get-sha1-hex (2023-07-24) 1 commit
  (merged to 'next' on 2023-07-27 at eeb9cc37f5)
 + hex: retire get_sha1_hex()
 The implementation of "get_sha1_hex()" that reads a hexadecimal
 string that spells a full object name has been extended to cope
 with any hash function used in the repository, but the "sha1" in
 its name survived.  Rename it to get_hash_hex(), a name that is
 more consistent within its friends like get_hash_hex_algop().
 Will merge to 'master'.
 source: <xmqq1qgwoqgo.fsf_-_@gitster.g>
* rs/parse-options-negation-help (2023-07-24) 5 commits
 - parse-options: show negatability of options in short help
 - t1502: test option negation
 - t1502: move optionspec help output to a file
 - t1502, docs: disallow --no-help
 - subtree: disallow --no-{help,quiet,debug,branch,message}
 "git cmd -h" learned to signal which options can be negated by
 listing such options like "--[no-]opt".
 Comments?
 Would showing "--[[no-]no-]opt" for "no-opt" be worth it?
 cf. <9e8225dd-1e8b-8af2-c3e1-0c5834694244@web.de>
 source: <4d01e971-07cb-4f11-3cc6-9d9f21e590c1@web.de>
* tb/commit-graph-tests (2023-07-24) 5 commits
  (merged to 'next' on 2023-07-31 at 740a260315)
 + t/lib-commit-graph.sh: avoid sub-shell in `graph_git_behavior()`
 + t5328: avoid top-level directory changes
 + t5318: avoid top-level directory changes
 + t/lib-commit-graph.sh: avoid directory change in `graph_git_behavior()`
 + t/lib-commit-graph.sh: allow `graph_read_expect()` in sub-directories
 Test updates.
 Will merge to 'master'.
 source: <cover.1690216758.git.me@ttaylorr.com>
* la/doc-choose-starting-point (2023-07-14) 5 commits
  (merged to 'next' on 2023-07-19 at 5a807cae46)
 + SubmittingPatches: simplify guidance for choosing a starting point
 + SubmittingPatches: emphasize need to communicate non-default starting points
 + SubmittingPatches: de-emphasize branches as starting points
 + SubmittingPatches: discuss subsystems separately from git.git
 + SubmittingPatches: reword awkward phrasing
 (this branch is used by la/doc-choose-starting-point-fixup.)
 Clarify how to choose the starting point for a new topic in
 developer guidance document.
 Will merge to 'master' together with the follow-on topic.
 source: <pull.1556.v2.git.1689314493.gitgitgadget@gmail.com>
* jc/doc-sent-patch-now-what (2023-07-27) 1 commit
  (merged to 'next' on 2023-07-31 at 51f5d9d465)
 + MyFirstContribution: refrain from self-iterating too much
 Process document update.
 Will merge to 'master'.
 source: <xmqqmszg987u.fsf_-_@gitster.g>
* jc/parse-options-short-help (2023-07-19) 3 commits
  (merged to 'next' on 2023-07-31 at e076d1f497)
 + short help: allow a gap smaller than USAGE_GAP
 + remote: simplify "remote add --tags" help text
 + short help: allow multi-line opthelp
 Command line parser fix, and a small parse-options API update.
 Will merge to 'master'.
 source: <xmqq5y6gg8fn.fsf@gitster.g>
* sl/sparse-check-attr (2023-07-18) 3 commits
 - check-attr: integrate with sparse-index
 - attr.c: read attributes in a sparse directory
 - t1092: add tests for 'git check-attr'
 Teach "git check-attr" work better with sparse-index.
 Expecting a reroll.
 cf. <c3ebe3b4-88b9-8ca2-2ee3-39a3e0d82201@github.com>
 cf. <5e478d8b-9ef4-864b-41e4-e0a79877d278@github.com>
 source: <20230718232916.31660-1-cheskaqiqi@gmail.com>
* jc/branch-in-use-error-message (2023-07-21) 1 commit
  (merged to 'next' on 2023-07-31 at 22f17d131b)
 + branch: update the message to refuse touching a branch in-use
 "git branch -f X" to repoint the branch X seid that X was "checked
 out" in another worktree, even when branch X was not and instead
 being bisected or rebased.  The message was reworded to say the
 branch was "in use".
 Will merge to 'master'.
 source: <xmqqr0p1szhz.fsf_-_@gitster.g>
* mh/credential-erase-improvements-more (2023-07-26) 2 commits
 - credential/wincred: erase matching creds only
 - credential/libsecret: erase matching creds only
 Update two credential helpers to correctly match which credential
 to erase; they dropped not the ones with stale password.
 Needs review.
 source: <pull.1527.v2.git.git.1690387585634.gitgitgadget@gmail.com>
 source: <pull.1529.git.git.1687596777147.gitgitgadget@gmail.com>
* cc/repack-sift-filtered-objects-to-separate-pack (2023-07-24) 8 commits
 . gc: add `gc.repackFilterTo` config option
 . repack: implement `--filter-to` for storing filtered out objects
 . gc: add `gc.repackFilter` config option
 . repack: add `--filter=<filter-spec>` option
 . repack: refactor finding pack prefix
 . repack: refactor finishing pack-objects command
 . t/helper: add 'find-pack' test-tool
 . pack-objects: allow `--filter` without `--stdout`
 "git repack" machinery learns to pay attention to the "--filter="
 option.
 Breaks CI with some environment variables configured.
 cf. <xmqqo7jzh9mh.fsf@gitster.g>
 source: <20230724085909.3831831-1-christian.couder@gmail.com>
* js/doc-unit-tests (2023-06-30) 1 commit
 - unit tests: Add a project plan document
 Process to add some form of low-level unit tests has started.
 Still filling in blanks.
 source: <0169ce6fb9ccafc089b74ae406db0d1a8ff8ac65.1688165272.git.steadmon@google.com>
* jt/path-filter-fix (2023-08-01) 7 commits
 - commit-graph: new filter ver. that fixes murmur3
 - repo-settings: introduce commitgraph.changedPathsVersion
 - t4216: test changed path filters with high bit paths
 - t/helper/test-read-graph: implement `bloom-filters` mode
 - bloom.h: make `load_bloom_filter_from_graph()` public
 - t/helper/test-read-graph.c: extract `dump_graph_info()`
 - gitformat-commit-graph: describe version 2 of BDAT
 The Bloom filter used for path limited history traversal was broken
 on systems whose "char" is unsigned; update the implementation and
 bump the format version to 2.
 Still under discussion.
 cf. <20230801185232.1457172-1-jonathantanmy@google.com>
 source: <cover.1690912539.git.jonathantanmy@google.com>
* mh/credential-libsecret-attrs (2023-06-16) 1 commit
 - credential/libsecret: store new attributes
 The way authentication related data other than passwords (e.g.
 oath token and password expiration data) are stored in libsecret
 keyrings has been rethought.
 Needs review.
 source: <pull.1469.v5.git.git.1686945306242.gitgitgadget@gmail.com>
* cc/git-replay (2023-06-03) 15 commits
 - replay: stop assuming replayed branches do not diverge
 - replay: add --contained to rebase contained branches
 - replay: add --advance or 'cherry-pick' mode
 - replay: disallow revision specific options and pathspecs
 - replay: use standard revision ranges
 - replay: make it a minimal server side command
 - replay: remove HEAD related sanity check
 - replay: remove progress and info output
 - replay: add an important FIXME comment about gpg signing
 - replay: don't simplify history
 - replay: introduce pick_regular_commit()
 - replay: die() instead of failing assert()
 - replay: start using parse_options API
 - replay: introduce new builtin
 - t6429: remove switching aspects of fast-rebase
 What's the status of this thing?
 source: <20230602102533.876905-1-christian.couder@gmail.com>

-------------------------------------------------- [Discarded]

* jc/doc-submodule-update-settings (2023-07-13) 1 commit
 . submodule: clarify that "!custom command" is the only oddball
 Rewrite the description of giving a custom command to the
 submodule.<name>.update configuraiton variable.
 Superseded by pv/doc-submodule-update-settings topic.
 source: <xmqqwmz3oacg.fsf@gitster.g>
* jc/rerere-read-rr-fix (2023-07-21) 1 commit
 . rerere: match the hash algorithm with its length
 SHA-256 fix.
 Superseded by jc/retire-get-sha1-hex
 source: <xmqqa5vou9ar.fsf@gitster.g>
* cb/checkout-same-branch-twice (2023-03-22) 2 commits
 . SQUASH??? the test marked to expect failure passes from day one
 . checkout/switch: disallow checking out same branch in multiple worktrees
 "git checkout -B $branch" failed to protect against checking out
 a branch that is checked out elsewhere, unlike "git branch -f" did.
 Have been expecting a hopefully minor and final reroll for too long.
 cf. <CAPUEspj_Bh+LgYLnWfeBdcq_uV5Cbou-7H51GLFjzSa5Qzby9w@mail.gmail.com>
 source: <20230120113553.24655-1-carenas@gmail.com>
* ed/fsmonitor-windows-named-pipe (2023-03-24) 1 commit
 . fsmonitor: handle differences between Windows named pipe functions
 Fix fsmonitor on Windows when the filesystem path contains certain
 characters.
 Have been expecting a reroll for too long.
 cf. <b9cf67e4-22a7-2ff0-8310-9223bea10d6d@jeffhostetler.com>
 source: <pull.1503.git.1679678090412.gitgitgadget@gmail.com>
* rn/sparse-diff-index (2023-04-10) 1 commit
 . diff-index: enable sparse index
 "git diff-index" command has been taught to work better with the
 sparse index.
 Have been expecting a reroll for too long.
 cf. <62821012-4fc3-5ad8-695c-70f7ab14a8c9@github.com>
 source: <20230408112342.404318-1-nanth.raghul@gmail.com>
* es/recurse-submodules-option-is-a-bool (2023-04-10) 1 commit
 . usage: clarify --recurse-submodules as a boolean
 The "--[no-]recurse-submodules" option of "git checkout" and others
 supported an undocumented syntax --recurse-submodules=<value> where
 the value can spell a Boolean in various ways.  The support for the
 syntax is being dropped.
 Have been expecting a reroll for too long.
 cf. <ZDSTFwMFO7vbj/du@google.com>
 source: <ZDSTFwMFO7vbj/du@google.com>
* jc/checkout-merge-fix (2023-07-28) 2 commits
 . checkout/restore: add basic tests for --merge
 . checkout/restore: refuse unmerging paths unless checking out of the index
 "git checkout/restore --merge -- $path" improvements.
 Superseded by jc/unresolve-removal
 source: <xmqq7cqj4rme.fsf@gitster.g>
* jc/resolve-undo-fixes (2023-07-28) 4 commits
 . update-index: remove stale fallback code for "--unresolve"
 . update-index: use unmerge_index_entry() to support removal
 . resolve-undo: allow resurrecting conflicted state that resolved to deletion
 . update-index: do not read HEAD and MERGE_HEAD unconditionally
 Assorted fixes and clean-up around resolve-undo data.
 Superseded by jc/unresolve-removal
 source: <xmqqo7jv4y0t.fsf_-_@gitster.g>
Taylor Blau· Aug 2, 2023, 19:09 UTC · re: Junio C Hamano · lore

jt/path-filter-fix (was: Re: What's cooking in git.git (Aug 2023, #01; Wed, 2))

On Wed, Aug 02, 2023 at 11:10:34AM -0700, Junio C Hamano wrote:
Show 16 quoted lines
> * jt/path-filter-fix (2023-08-01) 7 commits
>  - commit-graph: new filter ver. that fixes murmur3
>  - repo-settings: introduce commitgraph.changedPathsVersion
>  - t4216: test changed path filters with high bit paths
>  - t/helper/test-read-graph: implement `bloom-filters` mode
>  - bloom.h: make `load_bloom_filter_from_graph()` public
>  - t/helper/test-read-graph.c: extract `dump_graph_info()`
>  - gitformat-commit-graph: describe version 2 of BDAT
>
>  The Bloom filter used for path limited history traversal was broken
>  on systems whose "char" is unsigned; update the implementation and
>  bump the format version to 2.
>
>  Still under discussion.
>  cf. <20230801185232.1457172-1-jonathantanmy@google.com>
>  source: <cover.1690912539.git.jonathantanmy@google.com>

I am happy with the most recent round, but I think that it is probably a little late in the cycle to be merging down such a large change.

I wouldn't be opposed if you did so, but it may be worth waiting until we're on the other side of 2.42 so that other reviewers have a chance to look at this one as well.

Thanks, Taylor

Junio C Hamano· Aug 2, 2023, 19:20 UTC · re: Taylor Blau · lore

Re: jt/path-filter-fix

Taylor Blau <me@ttaylorr.com> writes:
Show 23 quoted lines
> On Wed, Aug 02, 2023 at 11:10:34AM -0700, Junio C Hamano wrote:
>> * jt/path-filter-fix (2023-08-01) 7 commits
>>  - commit-graph: new filter ver. that fixes murmur3
>>  - repo-settings: introduce commitgraph.changedPathsVersion
>>  - t4216: test changed path filters with high bit paths
>>  - t/helper/test-read-graph: implement `bloom-filters` mode
>>  - bloom.h: make `load_bloom_filter_from_graph()` public
>>  - t/helper/test-read-graph.c: extract `dump_graph_info()`
>>  - gitformat-commit-graph: describe version 2 of BDAT
>>
>>  The Bloom filter used for path limited history traversal was broken
>>  on systems whose "char" is unsigned; update the implementation and
>>  bump the format version to 2.
>>
>>  Still under discussion.
>>  cf. <20230801185232.1457172-1-jonathantanmy@google.com>
>>  source: <cover.1690912539.git.jonathantanmy@google.com>
>
> I am happy with the most recent round, but I think that it is probably a
> little late in the cycle to be merging down such a large change.
>
> I wouldn't be opposed if you did so, but it may be worth waiting until
> we're on the other side of 2.42 so that other reviewers have a chance to

Since I hear some folks (not just Google) base their own edition of Git on 'next', it probably is a good idea to merge it to 'next' and have their users help find potential issues in it, as I agree that the area it touches is important in the correctness department. Of course, it is important enough that the topic may very well want to be cooked longer than the usual "for at least one calendar week" in 'next', so I tend to agree that in a first few batches after the release may be the best time to have it graduate (if it turns out to be OK).

Thanks.
Taylor Blau· Aug 2, 2023, 19:28 UTC · re: Junio C Hamano · lore

Re: jt/path-filter-fix

On Wed, Aug 02, 2023 at 12:20:25PM -0700, Junio C Hamano wrote:
Show 35 quoted lines
> Taylor Blau <me@ttaylorr.com> writes:
>
> > On Wed, Aug 02, 2023 at 11:10:34AM -0700, Junio C Hamano wrote:
> >> * jt/path-filter-fix (2023-08-01) 7 commits
> >>  - commit-graph: new filter ver. that fixes murmur3
> >>  - repo-settings: introduce commitgraph.changedPathsVersion
> >>  - t4216: test changed path filters with high bit paths
> >>  - t/helper/test-read-graph: implement `bloom-filters` mode
> >>  - bloom.h: make `load_bloom_filter_from_graph()` public
> >>  - t/helper/test-read-graph.c: extract `dump_graph_info()`
> >>  - gitformat-commit-graph: describe version 2 of BDAT
> >>
> >>  The Bloom filter used for path limited history traversal was broken
> >>  on systems whose "char" is unsigned; update the implementation and
> >>  bump the format version to 2.
> >>
> >>  Still under discussion.
> >>  cf. <20230801185232.1457172-1-jonathantanmy@google.com>
> >>  source: <cover.1690912539.git.jonathantanmy@google.com>
> >
> > I am happy with the most recent round, but I think that it is probably a
> > little late in the cycle to be merging down such a large change.
> >
> > I wouldn't be opposed if you did so, but it may be worth waiting until
> > we're on the other side of 2.42 so that other reviewers have a chance to
>
> Since I hear some folks (not just Google) base their own edition of
> Git on 'next', it probably is a good idea to merge it to 'next' and
> have their users help find potential issues in it, as I agree that
> the area it touches is important in the correctness department.  Of
> course, it is important enough that the topic may very well want to
> be cooked longer than the usual "for at least one calendar week" in
> 'next', so I tend to agree that in a first few batches after the
> release may be the best time to have it graduate (if it turns out to
> be OK).

Yep, I agree with all of that. Thanks for juggling the merges, as always :-).

Thanks, Taylor

Rubén Justo· Aug 7, 2023, 20:59 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

On 2/8/23 20:10, Junio C Hamano wrote:
Show 5 quoted lines
> * rj/status-bisect-while-rebase (2023-08-01) 1 commit
>  - status: fix branch shown when not only bisecting
> 
>  "git status" is taught to show both the branch being bisected and
>  being rebased when both are in effect at the same time.
Maybe this suggest that something has been added, but only fixed.
Perhaps we can say something like:
   "git status" was not showing accurate information when bisect and
   other operation are in effect at the same time.
> 
>  Needs review.
>  source: <48745298-f12b-8efb-4e48-90d2c22a8349@gmail.com>
Thanks.
Jeff King· Aug 8, 2023, 19:22 UTC · re: Junio C Hamano · lore

leak in jt/path-filter-fix, was Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

On Wed, Aug 02, 2023 at 11:10:34AM -0700, Junio C Hamano wrote:
Show 16 quoted lines
> * jt/path-filter-fix (2023-08-01) 7 commits
>  - commit-graph: new filter ver. that fixes murmur3
>  - repo-settings: introduce commitgraph.changedPathsVersion
>  - t4216: test changed path filters with high bit paths
>  - t/helper/test-read-graph: implement `bloom-filters` mode
>  - bloom.h: make `load_bloom_filter_from_graph()` public
>  - t/helper/test-read-graph.c: extract `dump_graph_info()`
>  - gitformat-commit-graph: describe version 2 of BDAT
> 
>  The Bloom filter used for path limited history traversal was broken
>  on systems whose "char" is unsigned; update the implementation and
>  bump the format version to 2.
> 
>  Still under discussion.
>  cf. <20230801185232.1457172-1-jonathantanmy@google.com>
>  source: <cover.1690912539.git.jonathantanmy@google.com>

Since this hit 'next', Coverity complained about a small leak. Fixed by the patch below.

-- >8 --
Subject: [PATCH] commit-graph: fix small leak with invalid changedPathsVersion

When writing a commit graph, we sanity-check the value of commitgraph.changedPathsVersion and return early if it's invalid. But we only do so after allocating the write_commit_graph_context, meaing we leak it. We could "goto cleanup" to fix this, but instead let's push this check to the top of the function with the other early checks which return before doing any work.

Signed-off-by: Jeff King <peff@peff.net>
---
 commit-graph.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/commit-graph.c b/commit-graph.c
index 38edb12669..ccc21c6708 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -2372,6 +2372,12 @@ int write_commit_graph(struct object_directory *odb,
 	}
 	if (!commit_graph_compatible(r))
 		return 0;
+	if (r->settings.commit_graph_changed_paths_version < -1
+	    || r->settings.commit_graph_changed_paths_version > 2) {
+		warning(_("attempting to write a commit-graph, but 'commitgraph.changedPathsVersion' (%d) is not supported"),
+			r->settings.commit_graph_changed_paths_version);
+		return 0;
+	}
 
 	CALLOC_ARRAY(ctx, 1);
 	ctx->r = r;
@@ -2384,12 +2390,6 @@ int write_commit_graph(struct object_directory *odb,
 	ctx->write_generation_data = (get_configured_generation_version(r) == 2);
 	ctx->num_generation_data_overflows = 0;
 
-	if (r->settings.commit_graph_changed_paths_version < -1
-	    || r->settings.commit_graph_changed_paths_version > 2) {
-		warning(_("attempting to write a commit-graph, but 'commitgraph.changedPathsVersion' (%d) is not supported"),
-			r->settings.commit_graph_changed_paths_version);
-		return 0;
-	}
 	bloom_settings.hash_version = r->settings.commit_graph_changed_paths_version == 2
 		? 2 : 1;
 	bloom_settings.bits_per_entry = git_env_ulong("GIT_TEST_BLOOM_SETTINGS_BITS_PER_ENTRY",
-- 
2.42.0.rc0.376.g66bfc4f195
Jeff King· Aug 8, 2023, 19:25 UTC · re: Jeff King · lore

Re: leak in jt/path-filter-fix, was Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

On Tue, Aug 08, 2023 at 03:22:41PM -0400, Jeff King wrote:
Show 8 quoted lines
> Subject: [PATCH] commit-graph: fix small leak with invalid changedPathsVersion
> 
> When writing a commit graph, we sanity-check the value of
> commitgraph.changedPathsVersion and return early if it's invalid. But we
> only do so after allocating the write_commit_graph_context, meaing we
> leak it. We could "goto cleanup" to fix this, but instead let's push
> this check to the top of the function with the other early checks which
> return before doing any work.
I am tempted to do this on top, but maybe it is just churn. I dunno.
-- >8 --
Subject: [PATCH] commit-graph: store write context on stack rather than heap

In write_commit_graph(), we allocate our context struct on the heap. But there's no reason to do so, since it's small and we always free it when exiting the function. Converting it to a stack variable is slightly more efficient, but also can prevent some leaks (such as the one fixed in the previous commit, though to be fair this only helps for such a limited leak; once any sub-fields of the struct require allocation, it has to be cleaned up).

Signed-off-by: Jeff King <peff@peff.net>
---
 commit-graph.c | 140 ++++++++++++++++++++++++-------------------------
 1 file changed, 69 insertions(+), 71 deletions(-)
diff --git a/commit-graph.c b/commit-graph.c
index ccc21c6708..b8db056f37 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -2358,7 +2358,7 @@ int write_commit_graph(struct object_directory *odb,
 		       const struct commit_graph_opts *opts)
 {
 	struct repository *r = the_repository;
-	struct write_commit_graph_context *ctx;
+	struct write_commit_graph_context ctx;
 	uint32_t i;
 	int res = 0;
 	int replace = 0;
@@ -2379,16 +2379,16 @@ int write_commit_graph(struct object_directory *odb,
 		return 0;
 	}
 
-	CALLOC_ARRAY(ctx, 1);
-	ctx->r = r;
-	ctx->odb = odb;
-	ctx->append = flags & COMMIT_GRAPH_WRITE_APPEND ? 1 : 0;
-	ctx->report_progress = flags & COMMIT_GRAPH_WRITE_PROGRESS ? 1 : 0;
-	ctx->split = flags & COMMIT_GRAPH_WRITE_SPLIT ? 1 : 0;
-	ctx->opts = opts;
-	ctx->total_bloom_filter_data_size = 0;
-	ctx->write_generation_data = (get_configured_generation_version(r) == 2);
-	ctx->num_generation_data_overflows = 0;
+	memset(&ctx, 0, sizeof(ctx));
+	ctx.r = r;
+	ctx.odb = odb;
+	ctx.append = flags & COMMIT_GRAPH_WRITE_APPEND ? 1 : 0;
+	ctx.report_progress = flags & COMMIT_GRAPH_WRITE_PROGRESS ? 1 : 0;
+	ctx.split = flags & COMMIT_GRAPH_WRITE_SPLIT ? 1 : 0;
+	ctx.opts = opts;
+	ctx.total_bloom_filter_data_size = 0;
+	ctx.write_generation_data = (get_configured_generation_version(r) == 2);
+	ctx.num_generation_data_overflows = 0;
 
 	bloom_settings.hash_version = r->settings.commit_graph_changed_paths_version == 2
 		? 2 : 1;
@@ -2398,14 +2398,14 @@ int write_commit_graph(struct object_directory *odb,
 						  bloom_settings.num_hashes);
 	bloom_settings.max_changed_paths = git_env_ulong("GIT_TEST_BLOOM_SETTINGS_MAX_CHANGED_PATHS",
 							 bloom_settings.max_changed_paths);
-	ctx->bloom_settings = &bloom_settings;
+	ctx.bloom_settings = &bloom_settings;
 
 	init_topo_level_slab(&topo_levels);
-	ctx->topo_levels = &topo_levels;
+	ctx.topo_levels = &topo_levels;
 
-	prepare_commit_graph(ctx->r);
-	if (ctx->r->objects->commit_graph) {
-		struct commit_graph *g = ctx->r->objects->commit_graph;
+	prepare_commit_graph(ctx.r);
+	if (ctx.r->objects->commit_graph) {
+		struct commit_graph *g = ctx.r->objects->commit_graph;
 
 		while (g) {
 			g->topo_levels = &topo_levels;
@@ -2414,128 +2414,126 @@ int write_commit_graph(struct object_directory *odb,
 	}
 
 	if (flags & COMMIT_GRAPH_WRITE_BLOOM_FILTERS)
-		ctx->changed_paths = 1;
+		ctx.changed_paths = 1;
 	if (!(flags & COMMIT_GRAPH_NO_WRITE_BLOOM_FILTERS)) {
 		struct commit_graph *g;
 
-		g = ctx->r->objects->commit_graph;
+		g = ctx.r->objects->commit_graph;
 
 		/* We have changed-paths already. Keep them in the next graph */
 		if (g && g->bloom_filter_settings) {
-			ctx->changed_paths = 1;
-			ctx->bloom_settings = g->bloom_filter_settings;
+			ctx.changed_paths = 1;
+			ctx.bloom_settings = g->bloom_filter_settings;
 		}
 	}
 
-	if (ctx->split) {
-		struct commit_graph *g = ctx->r->objects->commit_graph;
+	if (ctx.split) {
+		struct commit_graph *g = ctx.r->objects->commit_graph;
 
 		while (g) {
-			ctx->num_commit_graphs_before++;
+			ctx.num_commit_graphs_before++;
 			g = g->base_graph;
 		}
 
-		if (ctx->num_commit_graphs_before) {
-			ALLOC_ARRAY(ctx->commit_graph_filenames_before, ctx->num_commit_graphs_before);
-			i = ctx->num_commit_graphs_before;
-			g = ctx->r->objects->commit_graph;
+		if (ctx.num_commit_graphs_before) {
+			ALLOC_ARRAY(ctx.commit_graph_filenames_before, ctx.num_commit_graphs_before);
+			i = ctx.num_commit_graphs_before;
+			g = ctx.r->objects->commit_graph;
 
 			while (g) {
-				ctx->commit_graph_filenames_before[--i] = xstrdup(g->filename);
+				ctx.commit_graph_filenames_before[--i] = xstrdup(g->filename);
 				g = g->base_graph;
 			}
 		}
 
-		if (ctx->opts)
-			replace = ctx->opts->split_flags & COMMIT_GRAPH_SPLIT_REPLACE;
+		if (ctx.opts)
+			replace = ctx.opts->split_flags & COMMIT_GRAPH_SPLIT_REPLACE;
 	}
 
-	ctx->approx_nr_objects = repo_approximate_object_count(the_repository);
+	ctx.approx_nr_objects = repo_approximate_object_count(the_repository);
 
-	if (ctx->append && ctx->r->objects->commit_graph) {
-		struct commit_graph *g = ctx->r->objects->commit_graph;
+	if (ctx.append && ctx.r->objects->commit_graph) {
+		struct commit_graph *g = ctx.r->objects->commit_graph;
 		for (i = 0; i < g->num_commits; i++) {
 			struct object_id oid;
 			oidread(&oid, g->chunk_oid_lookup + g->hash_len * i);
-			oid_array_append(&ctx->oids, &oid);
+			oid_array_append(&ctx.oids, &oid);
 		}
 	}
 
 	if (pack_indexes) {
-		ctx->order_by_pack = 1;
-		if ((res = fill_oids_from_packs(ctx, pack_indexes)))
+		ctx.order_by_pack = 1;
+		if ((res = fill_oids_from_packs(&ctx, pack_indexes)))
 			goto cleanup;
 	}
 
 	if (commits) {
-		if ((res = fill_oids_from_commits(ctx, commits)))
+		if ((res = fill_oids_from_commits(&ctx, commits)))
 			goto cleanup;
 	}
 
 	if (!pack_indexes && !commits) {
-		ctx->order_by_pack = 1;
-		fill_oids_from_all_packs(ctx);
+		ctx.order_by_pack = 1;
+		fill_oids_from_all_packs(&ctx);
 	}
 
-	close_reachable(ctx);
+	close_reachable(&ctx);
 
-	copy_oids_to_commits(ctx);
+	copy_oids_to_commits(&ctx);
 
-	if (ctx->commits.nr >= GRAPH_EDGE_LAST_MASK) {
+	if (ctx.commits.nr >= GRAPH_EDGE_LAST_MASK) {
 		error(_("too many commits to write graph"));
 		res = -1;
 		goto cleanup;
 	}
 
-	if (!ctx->commits.nr && !replace)
+	if (!ctx.commits.nr && !replace)
 		goto cleanup;
 
-	if (ctx->split) {
-		split_graph_merge_strategy(ctx);
+	if (ctx.split) {
+		split_graph_merge_strategy(&ctx);
 
 		if (!replace)
-			merge_commit_graphs(ctx);
+			merge_commit_graphs(&ctx);
 	} else
-		ctx->num_commit_graphs_after = 1;
+		ctx.num_commit_graphs_after = 1;
 
-	ctx->trust_generation_numbers = validate_mixed_generation_chain(ctx->r->objects->commit_graph);
+	ctx.trust_generation_numbers = validate_mixed_generation_chain(ctx.r->objects->commit_graph);
 
-	compute_topological_levels(ctx);
-	if (ctx->write_generation_data)
-		compute_generation_numbers(ctx);
+	compute_topological_levels(&ctx);
+	if (ctx.write_generation_data)
+		compute_generation_numbers(&ctx);
 
-	if (ctx->changed_paths)
-		compute_bloom_filters(ctx);
+	if (ctx.changed_paths)
+		compute_bloom_filters(&ctx);
 
-	res = write_commit_graph_file(ctx);
+	res = write_commit_graph_file(&ctx);
 
-	if (ctx->split)
-		mark_commit_graphs(ctx);
+	if (ctx.split)
+		mark_commit_graphs(&ctx);
 
-	expire_commit_graphs(ctx);
+	expire_commit_graphs(&ctx);
 
 cleanup:
-	free(ctx->graph_name);
-	free(ctx->commits.list);
-	oid_array_clear(&ctx->oids);
+	free(ctx.graph_name);
+	free(ctx.commits.list);
+	oid_array_clear(&ctx.oids);
 	clear_topo_level_slab(&topo_levels);
 
-	if (ctx->commit_graph_filenames_after) {
-		for (i = 0; i < ctx->num_commit_graphs_after; i++) {
-			free(ctx->commit_graph_filenames_after[i]);
-			free(ctx->commit_graph_hash_after[i]);
+	if (ctx.commit_graph_filenames_after) {
+		for (i = 0; i < ctx.num_commit_graphs_after; i++) {
+			free(ctx.commit_graph_filenames_after[i]);
+			free(ctx.commit_graph_hash_after[i]);
 		}
 
-		for (i = 0; i < ctx->num_commit_graphs_before; i++)
-			free(ctx->commit_graph_filenames_before[i]);
+		for (i = 0; i < ctx.num_commit_graphs_before; i++)
+			free(ctx.commit_graph_filenames_before[i]);
 
-		free(ctx->commit_graph_filenames_after);
-		free(ctx->commit_graph_filenames_before);
-		free(ctx->commit_graph_hash_after);
+		free(ctx.commit_graph_filenames_after);
+		free(ctx.commit_graph_filenames_before);
+		free(ctx.commit_graph_hash_after);
 	}
 
-	free(ctx);
-
 	return res;
 }
 
-- 
2.42.0.rc0.376.g66bfc4f195
Taylor Blau· Aug 8, 2023, 20:22 UTC · re: Jeff King · lore

Re: leak in jt/path-filter-fix, was Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

On Tue, Aug 08, 2023 at 03:22:40PM -0400, Jeff King wrote:
> Since this hit 'next', Coverity complained about a small leak. Fixed by
> the patch below.

The patch below looks good and makes sense to me. That warning is awfully long, though ;-).

In any event, I expect that 'next' will be rewound before this topic graduates, since it is meaty and we are in the middle of the -rc phase.

...and we also have my series on top [1], so it may be worthwhile for you, Jonathan, and I to figure out how to combine our efforts here. I think that this could likely get squashed in to Jonathan's topic if/after it gets ejected from 'next'. We can take my patches together in the same series, separately in a different one, or discard them altogether.

If we do decide to pursue the approach in [1], I think combining everything together into one big series makes the most sense for ease of merging.

[1]: https://lore.kernel.org/git/ZMv14grkM7x7Sf8m@nand.local/

Thanks, Taylor

Jeff King· Aug 8, 2023, 21:19 UTC · re: Taylor Blau · lore

Re: leak in jt/path-filter-fix, was Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

On Tue, Aug 08, 2023 at 04:22:14PM -0400, Taylor Blau wrote:
Show 20 quoted lines
> On Tue, Aug 08, 2023 at 03:22:40PM -0400, Jeff King wrote:
> > Since this hit 'next', Coverity complained about a small leak. Fixed by
> > the patch below.
> 
> The patch below looks good and makes sense to me. That warning is
> awfully long, though ;-).
> 
> In any event, I expect that 'next' will be rewound before this topic
> graduates, since it is meaty and we are in the middle of the -rc phase.
> 
> ...and we also have my series on top [1], so it may be worthwhile for
> you, Jonathan, and I to figure out how to combine our efforts here. I
> think that this could likely get squashed in to Jonathan's topic
> if/after it gets ejected from 'next'. We can take my patches together in
> the same series, separately in a different one, or discard them
> altogether.
> 
> If we do decide to pursue the approach in [1], I think combining
> everything together into one big series makes the most sense for ease of
> merging.

Yeah, I am just coming back from vacation and didn't follow all of the discussion on this topic carefully. The few patches I sent today were just enough to get the test suite passing again (the send-email fixes) and silence any new Coverity warnings. ;)

If it does get re-rolled, I would be quite happy if my fix here just gets squashed into the appropriate commit.

-Peff
Jonathan Tan· Aug 11, 2023, 22:15 UTC · re: Taylor Blau · lore

Re: leak in jt/path-filter-fix, was Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

Taylor Blau <me@ttaylorr.com> writes:
Show 25 quoted lines
> On Tue, Aug 08, 2023 at 03:22:40PM -0400, Jeff King wrote:
> > Since this hit 'next', Coverity complained about a small leak. Fixed by
> > the patch below.
> 
> The patch below looks good and makes sense to me. That warning is
> awfully long, though ;-).
> 
> In any event, I expect that 'next' will be rewound before this topic
> graduates, since it is meaty and we are in the middle of the -rc phase.
> 
> ...and we also have my series on top [1], so it may be worthwhile for
> you, Jonathan, and I to figure out how to combine our efforts here. I
> think that this could likely get squashed in to Jonathan's topic
> if/after it gets ejected from 'next'. We can take my patches together in
> the same series, separately in a different one, or discard them
> altogether.
> 
> If we do decide to pursue the approach in [1], I think combining
> everything together into one big series makes the most sense for ease of
> merging.
> 
> [1]: https://lore.kernel.org/git/ZMv14grkM7x7Sf8m@nand.local/
> 
> Thanks,
> Taylor
For what it's worth, whatever we decide sounds good to me.
Christian Couder· Aug 7, 2023, 12:41 UTC · lore

Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

(Sorry I somehow forgot to put the mailing list in Cc: of this.)

On Fri, Aug 4, 2023 at 10:15 AM Christian Couder <christian.couder@gmail.com> wrote:

Show 50 quoted lines
>
> On Wed, Aug 2, 2023 at 10:55 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> > * cc/repack-sift-filtered-objects-to-separate-pack (2023-07-24) 8 commits
> >  . gc: add `gc.repackFilterTo` config option
> >  . repack: implement `--filter-to` for storing filtered out objects
> >  . gc: add `gc.repackFilter` config option
> >  . repack: add `--filter=<filter-spec>` option
> >  . repack: refactor finding pack prefix
> >  . repack: refactor finishing pack-objects command
> >  . t/helper: add 'find-pack' test-tool
> >  . pack-objects: allow `--filter` without `--stdout`
> >
> >  "git repack" machinery learns to pay attention to the "--filter="
> >  option.
> >
> >  Breaks CI with some environment variables configured.
> >  cf. <xmqqo7jzh9mh.fsf@gitster.g>
> >  source: <20230724085909.3831831-1-christian.couder@gmail.com>
>
> I am working on this and hope to send a version 4 soon.
>
> > * cc/git-replay (2023-06-03) 15 commits
> >  - replay: stop assuming replayed branches do not diverge
> >  - replay: add --contained to rebase contained branches
> >  - replay: add --advance or 'cherry-pick' mode
> >  - replay: disallow revision specific options and pathspecs
> >  - replay: use standard revision ranges
> >  - replay: make it a minimal server side command
> >  - replay: remove HEAD related sanity check
> >  - replay: remove progress and info output
> >  - replay: add an important FIXME comment about gpg signing
> >  - replay: don't simplify history
> >  - replay: introduce pick_regular_commit()
> >  - replay: die() instead of failing assert()
> >  - replay: start using parse_options API
> >  - replay: introduce new builtin
> >  - t6429: remove switching aspects of fast-rebase
> >
> >  What's the status of this thing?
> >  source: <20230602102533.876905-1-christian.couder@gmail.com>
>
> I have a 2 week long vacation starting soon, so I will likely not have
> time to work on a new round in the next 3 weeks.
>
> However in a recent article
> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)
> GitHub says that they are already using git-replay (though not sure
> it's this exact version or another one), and GitLab plans to use it
> too. So I guess it's worth keeping.
Junio C Hamano· Aug 7, 2023, 16:19 UTC · re: Christian Couder · lore

Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

Christian Couder <christian.couder@gmail.com> writes:
> (Sorry I somehow forgot to put the mailing list in Cc: of this.)

This seems to be a response to an older issue of the report, but I take it that the status of these two topics haven't changed since then.

Show 7 quoted lines
>> > * cc/repack-sift-filtered-objects-to-separate-pack (2023-07-24) 8 commits
>> > ...
>> >  Breaks CI with some environment variables configured.
>> >  cf. <xmqqo7jzh9mh.fsf@gitster.g>
>> >  source: <20230724085909.3831831-1-christian.couder@gmail.com>
>>
>> I am working on this and hope to send a version 4 soon.
Sounds good.  Thanks.
Show 8 quoted lines
>> > * cc/git-replay (2023-06-03) 15 commits
>> > ...
>> >
>> >  What's the status of this thing?
>> >  source: <20230602102533.876905-1-christian.couder@gmail.com>
>>
>> I have a 2 week long vacation starting soon, so I will likely not have
>> time to work on a new round in the next 3 weeks.
OK.  Enjoy.
Show 5 quoted lines
>> However in a recent article
>> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)
>> GitHub says that they are already using git-replay (though not sure
>> it's this exact version or another one), and GitLab plans to use it
>> too.

So there are plenty folks who are capable of reviewing but they are not interested in giving it to the general public by withholding their reviews ;-)?

Taylor Blau· Aug 7, 2023, 16:22 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

On Mon, Aug 07, 2023 at 09:19:08AM -0700, Junio C Hamano wrote:
Show 9 quoted lines
> >> However in a recent article
> >> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)
> >> GitHub says that they are already using git-replay (though not sure
> >> it's this exact version or another one), and GitLab plans to use it
> >> too.
>
> So there are plenty folks who are capable of reviewing but they are
> not interested in giving it to the general public by withholding
> their reviews ;-)?

I think the most capable reviewer would be Johannes, who was most involved the Git-related parts of this work at GitHub.

I was party to most of the changes that went through in this area, but didn't look closely.

Thanks, Taylor

Elijah Newren· Aug 7, 2023, 16:56 UTC · re: Junio C Hamano · lore

Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

On Mon, Aug 7, 2023 at 9:19 AM Junio C Hamano <gitster@pobox.com> wrote:
>
[...]
Show 9 quoted lines
> >> However in a recent article
> >> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)
> >> GitHub says that they are already using git-replay (though not sure
> >> it's this exact version or another one), and GitLab plans to use it
> >> too.
>
> So there are plenty folks who are capable of reviewing but they are
> not interested in giving it to the general public by withholding
> their reviews ;-)?

I can see how one could jump to that conclusion, but I don't think it's warranted. I have a little information that might shed some light:

-----

At the beginning of July, well before the above link came out, Johannes sent me an email pointing me at https://github.blog/changelog/2023-06-28-rebase-commits-now-created-using-the-merge-ort-strategy/. In the email, he also noted my earlier stated concerns on the list (about releasing `replay` early possibly painting us into a corner preventing some desired goals for the tool from being realized), and tried to ensure we could still work towards having a `replay` command like the one I envisioned while also asking for my thoughts on pushing for the current portion of work to be published and included in git. My sense was he was pushing for the work to be released, but just being careful about my concerns first.

Unfortunately, I was on vacation that week, and sadly have otherwise been buried in coming up to speed on a new team and haven't had time to even respond to git-related stuff. I didn't respond to him until late last week.

I pointed out that the 'EXPERIMENTAL' banner addresses most of my concerns so it should be fine to move forward, but I suspect my delay has resulted in him now being buried in other matters, and in the mean-time the article Christian highlighted was produced by others.

-----

Anyway, hope that helps. I did review V2 and have been meaning to comment on V3 (and respond to Toon's comments), though not sure my "review" counts as such since I'm the original author of most of the patches...

(And sorry for being missing in action. I've flagged a few other emails that I'm hoping I can follow up on, but my time is currently quite limited...)

Johannes Schindelin· Aug 17, 2023, 13:21 UTC · re: Elijah Newren · lore

Re: What's cooking in git.git (Aug 2023, #01; Wed, 2)

Hi,
On Mon, 7 Aug 2023, Elijah Newren wrote:
Show 30 quoted lines
> On Mon, Aug 7, 2023 at 9:19 AM Junio C Hamano <gitster@pobox.com> wrote:
> >
> [...]
> > >> However in a recent article
> > >> (https://github.blog/2023-07-27-scaling-merge-ort-across-github/)
> > >> GitHub says that they are already using git-replay (though not sure
> > >> it's this exact version or another one), and GitLab plans to use it
> > >> too.
> >
> > So there are plenty folks who are capable of reviewing but they are
> > not interested in giving it to the general public by withholding
> > their reviews ;-)?
>
> I can see how one could jump to that conclusion, but I don't think
> it's warranted.  I have a little information that might shed some
> light:
>
> -----
>
> At the beginning of July, well before the above link came out,
> Johannes sent me an email pointing me at
> https://github.blog/changelog/2023-06-28-rebase-commits-now-created-using-the-merge-ort-strategy/.
> In the email, he also noted my earlier stated concerns on the list
> (about releasing `replay` early possibly painting us into a corner
> preventing some desired goals for the tool from being realized), and
> tried to ensure we could still work towards having a `replay` command
> like the one I envisioned while also asking for my thoughts on pushing
> for the current portion of work to be published and included in git.
> My sense was he was pushing for the work to be released, but just
> being careful about my concerns first.

Indeed. The patches that are running on GitHub to support rebases incorporate v3 of the `git-replay` patch series, and add a couple of patches on top to perform rebases similar to how things were done using libgit2 before.

Show 9 quoted lines
> Unfortunately, I was on vacation that week, and sadly have otherwise
> been buried in coming up to speed on a new team and haven't had time
> to even respond to git-related stuff.  I didn't respond to him until
> late last week.
>
> I pointed out that the 'EXPERIMENTAL' banner addresses most of my
> concerns so it should be fine to move forward, but I suspect my delay
> has resulted in him now being buried in other matters, and in the
> mean-time the article Christian highlighted was produced by others.
The article was produced with my input, so I cannot claim innocence.

The reason why I did not respond earlier is that I wanted to have more time to push forward with your vision of `git replay`, in a direction where it avoids repeating the design of `git rebase`.

About integrating the current patch series as-is, I would be fine with it. The best support I can offer is that this code (with minor changes that do not fundamentally modify how the core logic works) has performed gazillions of rebases in the meantime.

We just need to be mindful to keep that EXPERIMENTAL label until we fully implement the design Elijah envisions. Which might very well need the user interface to change rather drastically.

Show 8 quoted lines
> Anyway, hope that helps.  I did review V2 and have been meaning to
> comment on V3 (and respond to Toon's comments), though not sure my
> "review" counts as such since I'm the original author of most of the
> patches...
>
> (And sorry for being missing in action.  I've flagged a few other
> emails that I'm hoping I can follow up on, but my time is currently
> quite limited...)
I haven't been a frequent guest on the Git mailing list, either, lately...

Ciao, Johannes

← back to recent threads