Standard Library Sync: September 24th, 2025

[hamzaremmal]

Superseed #24062

Steps to reproduce:

git clone git@github.com:scala/scala.git --single-branch --no-tags --branch 2.13.x embed
cd embed
git filter-repo --path src/library --path-rename src/library:library/src
git filter-repo --message-callback 'return re.sub(rb"(?<!\w)#(\d+)", rb"scala/scala#\1", message)'
git remote add scala3 git@github.com:scala/scala3.git
git fetch scala3
git replace --graft b594c22eac364ca2449a2700506b4f6b3f571b86 2308509d2651ee78e1122b5d61b798c984c96c4d
git filter-repo --proceed
git checkout -b stdlib-history
git checkout -b sync-24-09-2025 scala3/main
git merge stdlib-history # Also fix the two conflicts that occurred
git push scala3

[lrytz]

Some merge commits show up (scala/scala#11059), but not all (scala/scala#11061, scala/scala#11098). 🤷‍♂️ I guess?

What is unfortunate here is that navigating the history of a change will become a lot more difficult. In a few years, if someone wonders about the history of e8534ef (for example), how would they find their way from there to discussion on scala/scala#11098?

Amending the commit messages to link to the original commit on scala/scala (scala/scala@bd6bdf8 in this case) would solve it. But I assume that ship has sailed for the library history that is already in scala/scala3 today?

[sjrd]

Oh, that is unfortunate, indeed. I never thought about that.

But I assume that ship has sailed for the library history that is already in scala/scala3 today?

No ship has ever truly sailed in git land. But in this case, the cost of fixing it probably exceeds what any of us is willing to spend in git hackery. In particular it would mean rewriting the history of scala3/main since the first merge with new SHAs.

One mitigation would be to expose an external index of corresponding commits, that we could look up manually.