Re: What's cooking in git.git (Nov 2025, #07; Sun, 23)

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> I tried to take a look at some of the series whose status you were
> asking for feedback on (and just threw an extra comment on one that
> you didn't ask about).  Comments below...
>
> On Sun, Nov 23, 2025 at 8:59 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> * jc/optional-path (2025-11-20) 3 commits
>> ...
>>  Will merge to 'next'?
>>  source: <xmqqikf47ajk.fsf@gitster.g>
>
> This topic seems to be missing a squashed-in fix from
> xmqqy0o05nuy.fsf@gitster.g; should that be squashed in and then merge
> down to next?

Thanks for carefully checking.  The second patch with yesterday's
committer timestamp has the squash, so it seems that our mails
crossed ;-)

>> * js/ci-show-breakage-in-dockerized-jobs (2025-11-17) 1 commit
>> ...
>>  Will merge to 'next' after amending?
>>  cf. <xmqqpl9gike6.fsf@gitster.g>
>>  source: <pull.2003.git.1763399064983.gitgitgadget@gmail.com>
>
> I had a slight tweak for the wording of the first paragraph, which I
> just left as a comment on the patch.  Not sure that needs to hold it
> up, but maybe worth considering to include in your amending if
> Johannes is fine with it?

FWIW, I found the updated explanation you gave easier to read than
the original.  I still do not think of a reason why we want a more
conservative o+w when making things world-writable, other than the
case where there is a user in the same group as the owner of the
file that we specifically want to forbid touching it, but then I do
not have any idea who that special user in the same group would be.

>> * js/strip-scalar-too (2025-11-17) 1 commit
>>  - make strip: include `scalar`
>>
>>  "make strip" has been taught to strip "scalar" as well as "git".
>>
>>  Will merge to 'next'?
>>  cf. <xmqq7bvoiadg.fsf@gitster.g>
>>  source: <pull.2004.git.1763409086322.gitgitgadget@gmail.com>
>
> I'd kind of like to see a response to your suggested alternative.

I am OK if we applied the patch posted as-is, and left such a
clean-up as #leftoverbits.

>> * dw/config-global-list (2025-10-09) 4 commits
>> ...
>>  Comments?
>>  source: <pull.1938.git.1760058849.gitgitgadget@gmail.com>
>
> Perhaps mark this topic as expecting a re-roll?  (c.f.
> 20251122020047.GB3947@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net)

Great.  That's an awfully long message-id, by the way ;-)

>> * jc/submodule-add (2025-11-15) 1 commit
>>  - submodule add: sanity check existing .gitmodules
>>
>>  "git submodule add" to add a submodule under <name> segfaulted,
>>  when a submodule.<name>.something is already in .gitmodules file
>>  without defining where its submodule.<name>.path is, which has been
>>  corrected.
>>
>>  Comments?
>>  source: <xmqqv7jacvdq.fsf@gitster.g>
>
> Left a couple minor wording suggestions.

Thanks; amended.

>> * en/ort-rename-another-fix (2025-11-03) 3 commits
>>   (merged to 'next' on 2025-11-19 at 53d94af6b4)
>>  + merge-ort: fix failing merges in special corner case
>>  + merge-ort: remove debugging crud
>>  + t6429: update comment to mention correct tool
>>
>>  Yet another corner case fix around renames in the "ort" merge
>>  strategy.
>>
>>  Will merge to 'master'.
>>  source: <pull.1992.git.1762192908.gitgitgadget@gmail.com>
>
> A sidenote that probably doesn't matter since you've already marked it
> for merging down: this topic has been deployed at GitHub for just over
> a month without incident (whereas there were some problems prior to
> deploying these fixes, and those problems cleared up the minute that
> these changes were deployed).

Great to hear.

>> * cc/fast-import-strip-if-invalid (2025-11-16) 3 commits
>>  - fast-import: add 'strip-if-invalid' mode to --signed-commits=<mode>
>>  - commit: refactor verify_commit_buffer()
>>  - fast-import: refactor finalize_commit_buffer()
>>
>>  "git fast-import" learns "--strip-if-invalid" option to drop
>>  invalid cryptographic signature from objects.
>>
>>  Comments?
>>  source: <20251117043450.322644-1-christian.couder@gmail.com>
>
> I think this one is ready to merge down.
>
>> * en/xdiff-cleanup-2 (2025-11-18) 10 commits
>>  - xdiff: rename rindex -> reference_index
>>  - xdiff: change rindex from long to size_t in xdfile_t
>>  - xdiff: make xdfile_t.nreff a size_t instead of long
>>  - xdiff: make xdfile_t.nrec a size_t instead of long
>>  - xdiff: split xrecord_t.ha into line_hash and minimal_perfect_hash
>>  - xdiff: use unambiguous types in xdl_hash_record()
>>  - xdiff: use size_t for xrecord_t.size
>>  - xdiff: make xrecord_t.ptr a uint8_t instead of char
>>  - xdiff: use ptrdiff_t for dstart/dend
>>  - doc: define unambiguous type mappings across C and Rust
>>
>>  Code clean-up.
>>
>>  Will merge to 'next'?
>>  source: <pull.2070.v5.git.git.1763505262.gitgitgadget@gmail.com>
>
> I think so.  There are certainly additional cleanups needed, as this
> series makes clear, but that's clearly a bigger problem and the author
> has stated he plans to work on those but just needed to limit the
> series to some initial cleanup that wasn't too big to send to the
> list.  The series has gotten reviews from lots of folks, and I just
> looked over v5 and couldn't spot anything to call out.

Great, and thanks.