Documentation/RelNotes: improve release note for rename detection work
PATCH 1/1 Documentation/RelNotes: improve release note for rename detection work
From: Elijah Newren <[email protected]>
There were some early changes in the 2.31 cycle to optimize some setup in diffcore-rename.c[1], some later changes to measure performance[2], and finally some significant changes to improve rename detection performance. The final one was merged with the note
Performance optimization work on the rename detection continues.
That works for the commit log, but feels misleading as a release note since all the changes were within one cycle. Simplify this to just
Performance improvements for rename detection.
The former wording could be seen as hinting that more performance improvements will come in 2.32, which is true, but we can just cover those in the 2.32 release notes when the time comes.
[1] a5ac31b5b1 (Merge branch 'en/diffcore-rename', 2021-01-25)
[2] d3a035b055 (Merge branch 'en/merge-ort-perf', 2021-02-11)
[3] 12bd17521c (Merge branch 'en/diffcore-rename', 2021-03-01)
---
Documentation/RelNotes: improve release note for rename detection work
Just a tiny release note tweak
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-974%2Fnewren%2Frelease-notes-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-974/newren/release-notes-v1
Pull-Request: https://github.com/git/git/pull/974
Documentation/RelNotes/2.31.0.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/RelNotes/2.31.0.txt +1 -1
@@ -199,7 +199,7 @@ Performance, Internal Implementation, Development Support etc. * Preliminary changes to fsmonitor integration. - * Performance optimization work on the rename detection continues. + * Performance improvements for rename detection. * The common code to deal with "chunked file format" that is shared by the multi-pack-index and commit-graph files have been factored
base-commit: f01623b2c9d14207e497b21ebc6b3ec4afaf4b46
Signature · 1 line
gitgitgadget
Quoted 2 lines · Elijah Newren via GitGitGadget
The former wording could be seen as hinting that more performance improvements will come in 2.32, which is true, but ...
It is somewhat dissappointing to hear that, as the above "hinting" was exactly what I wanted to achieve by leaving "continues" in there.
Will queue, though.
Quoted 9 lines · Junio C Hamano
Quoted 2 lines · Elijah Newren via GitGitGadget
The former wording could be seen as hinting that more performance improvements will come in 2.32, which is true, but ...
It is somewhat dissappointing to hear that, as the above "hinting" was exactly what I wanted to achieve by leaving "continues" in there.
Ah. I actually threw that last paragraph into the commit message almost as an afterthought. Perhaps "commences" or "has begun" instead of "continues" would have worked? When I saw "continues" it just looked to me like an accidental copy of the commit message and one that could be misleading, so I thought I'd flag it.
Quoted 1 line
Will queue, though.