v2.45.2.vfs.0.2

[dscho]

What's Changed

• Fix a git restore bug where it would fail with "did not match any file(s) known to git" by @derrickstolee in checkout: ignore skip-worktree when virtual #658
• Avoid putting GVFS packs into the local object directory of Scalar clones instead of shared object directory by @derrickstolee in fixup! sha1-file: create shared-cache directory if it doesn't exist #660
• README: adjust the currently-broken GVFS Protocol link by @dscho in README: adjust the currently-broken GVFS Protocol link #661
• git status: print hydration level by @jeffhostetler in virtualization: add new builtin command to print hydration level #659
• microsoft/git's release builds now use the Azure Federated login mechanism by @mjcheetham in Use Azure Federated login mechanism rather than secrets #662
• trace2: help diagnosing problems when telemetry misses events by @jeffhostetler in trace2: prefetch value of GIT_TRACE2_DST_DEBUG at startup #663
• Avoid a costly fall-back when GVFS cache servers experience network problems by @derrickstolee and @jeffhostetler in gvfs-helper: add gvfs.fallback and unit tests #665
• Add the experimental git survey command to analyze (large) local repositories by @jeffhostetler in Add the experimental git survey command to analyze (large) local repositories #667

Full Changelog: v2.45.2.vfs.0.1...v2.45.2.vfs.0.2

---

This discussion was created from the release v2.45.2.vfs.0.2.

[dscho]

For the record: I just promoted this to a full release and marked it as the latest version.

I heard of no problems other than a minor issue with the new, experimental git survey command where it may print unexpected blob sizes. Since this is experimental and subject to be iterated on rapidly, I did not consider this a blocker.

[dscho]

v2.45.2.vfs.0.3 is now available as a pre-release.

[YehezkelShB]

For some reason, GitHub still shows v2.45.2.vfs.0.2 as pre-release instead of latest (and v2.45.2.vfs.0.1 is still linked from the main page as latest)

[dscho]

Yes, it still is a pre-release because I have not heard of anybody who tested this successfully. I want to avoid marking it as the latest release unless I have test reports to increase the confidence that this version won't break users' workflows.

For example, v2.45.2.vfs.0.2 introduced a performance regression that forced us to pull this version. Despite the care we try to exercise, Git is too complex to fully prevent issues like this. However, promoting to the latest release only to then pull it again is an unideal way to deal with issues like this. It is much better that stakeholders test the pre-releases, then report back their findings, and once we gained enough confidence that it will be a solid release, we promote it to the latest release.

Please take this as very strong motivation to thoroughly test the pre-release!

[dscho]

@YehezkelShB oh, I just realized that you were talking about v2.45.2.vfs.0.2! See this previous comment in this here discussion that explains why it had to be pulled.

[YehezkelShB]

Oh, missed this. I just knew I got this version locally after auto-update :D
Thanks!