Re: [PATCH v5 1/2] scripts: generate_rust_analyzer.py: add versioning infrastructure

From: Tamir Duberstein

Date: Sun May 03 2026 - 09:22:08 EST


On Sat, May 2, 2026 at 2:26 AM Jesung Yang <y.j3ms.n@xxxxxxxxx> wrote:
>
> On Sat, May 2, 2026 at 12:39 AM Tamir Duberstein <tamird@xxxxxxxxxx> wrote:
> >
> > Here's what I see locally:
> >
> > % bash check.sh 1.85.0
> > + RUST_VERSION=1.85.0
> > + LOOKAHEAD=50
> > ++ git -C ./rust log -n 50 --format=%s 1.85.0 -- src/tools/rust-analyzer
> > ++ grep 'Merge pull request #'
> > + subject_string=
> > % echo $?
> > 1
> >
> > So it seems to never get past `git log` in the rust repo. When I run
> > that git log manually I see nothing containing "Merge pull request
> > ...":
> >
> > % git -C ./rust log -n 50 --format=%s 1.85.0 -- src/tools/rust-analyzer
> > Disable some incorrect rust-analyzer diagnostics on beta
> > Backport rust-lang/rust-analyzer#18760: internal: Workaround salsa
> > cycles leaking
> > Bump rustc crates
> > Preparing for merge from rust-lang/rust
> [...]
> >
> > What's also interesting is that when I use `--merges` I get no commits at all:
> >
> > % git -C ./rust log -n1 --merges --format=%s 1.85.0 -- src/tools/rust-analyzer
> > %
> >
> > Something strange is happening; my git is not behaving the same as your git.
>
> I tested the procedure on a fresh Ubuntu 24.04 container using git
> 2.43.0, and it works as expected: merge commits are not lost, and the
> script provides the matching release page link. What does your git
> configuration look like? Perhaps some local settings are preventing
> merge commits from being displayed?

Indeed. Codex figured it out:

The cause is your global Git config. You have:

git config --show-origin --get log.follow
# file:/Users/tamird/.gitconfig true

That affects /Users/tamird/code/check.sh:9: with a single pathspec,
git log ... -- src/tools/rust-analyzer behaves as if --follow was
passed. In this non-linear subtree history, --follow drops the merge
commits, so the grep for Merge pull request # finds nothing.

Best script fix: make that command immune to user config, e.g. add
--no-follow or use git -c log.follow=false -C ./rust log ....

Secondary issue: after this is fixed, macOS /bin/bash here is 3.2 and
does not have readarray, so /Users/tamird/code/check.sh:12 will hit
another portability failure on this machine.

Mind incorporating these fixes in the next version?