RelNotes: fix a couple of typos for the upcoming release
PATCH 1/1 RelNotes: fix a couple of typos for the upcoming release
From: Johannes Schindelin <[email protected]>
---
RelNotes: fix a couple of typos for the upcoming release
I noticed one of them while reviewing the Git for Windows rebase, and decided to give VS Code with cSpell a whirl.
Note: cSpell pointed out more words it deems not to be English, such as docfix and leakfix and segfaulted. I was on the fence, but figured that those are "Git speak", so I left them alone.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1073%2Fdscho%2Ffix-relnotes-typos-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1073/dscho/fix-relnotes-typos-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1073
Documentation/RelNotes/2.34.0.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Documentation/RelNotes/2.34.0.txt +2 -2
@@ -182,7 +182,7 @@ Performance, Internal Implementation, Development Support etc. * Prevent "make sparse" from running for the source files that haven't been modified. - * The codepath to write a new version of .midx multi-pack index files + * The code path to write a new version of .midx multi-pack index files has learned to release the mmaped memory holding the current version of .midx before removing them from the disk, as some platforms do not allow removal of a file that still has mapping.
@@ -405,7 +405,7 @@ Fixes since v2.33 (merge 47bfdfb3fd ar/fix-git-pull-no-verify later to maint). * One CI task based on Fedora image noticed a not-quite-kosher - consturct recently, which has been corrected. + construct recently, which has been corrected. (merge 4b540cf913 vd/pthread-setspecific-g11-fix later to maint). * Other code cleanup, docfix, build fix, etc.
base-commit: 6c220937e2b26d85920bf2d38ff2464a0d57fd6b
Signature · 1 line
gitgitgadget
"Johannes Schindelin via GitGitGadget" <[email protected]>
Quoted 5 lines · writes:
From: Johannes Schindelin <[email protected]>
Signed-off-by Johannes Schindelin <[email protected]>---
RelNotes: fix a couple of typos for the upcoming release
Thanks. Relative to -rc2, here is what I have today, taking these typofixes, and a few topics for regression fixes.
Documentation/RelNotes/2.34.0.txt +20 -7
@@ -77,7 +77,10 @@ UI, Workflows & Features * "git fsck" has been taught to report mismatch between expected and actual types of an object better. - * Use ssh public crypto for object and push-cert signing. + * In addition to GnuPG, ssh public crypto can be used for object and + push-cert signing. Note that this feature cannot be used with + ssh-keygen from OpenSSH 8.7, whose support for it is broken. Avoid + using it unless you update to OpenSSH 8.8. * "git log --grep=string --author=name" learns to highlight hits just like "git grep string" does.
@@ -182,7 +185,7 @@ Performance, Internal Implementation, Development Support etc. * Prevent "make sparse" from running for the source files that haven't been modified. - * The codepath to write a new version of .midx multi-pack index files + * The code path to write a new version of .midx multi-pack index files has learned to release the mmaped memory holding the current version of .midx before removing them from the disk, as some platforms do not allow removal of a file that still has mapping.
@@ -260,12 +263,8 @@ Fixes since v2.33 * The output from "git fast-export", when its anonymization feature is in use, showed an annotated tag incorrectly. - * Doc update plus improved error reporting. - * Recent "diff -m" changes broke "gitk", which has been corrected. - * Regression fix. - * The "git apply -3" code path learned not to bother the lower level merge machinery when the three-way merge can be trivially resolved without the content level merge. This fixes a regression caused by
@@ -405,9 +404,23 @@ Fixes since v2.33 (merge 47bfdfb3fd ar/fix-git-pull-no-verify later to maint). * One CI task based on Fedora image noticed a not-quite-kosher - consturct recently, which has been corrected. + construct recently, which has been corrected. (merge 4b540cf913 vd/pthread-setspecific-g11-fix later to maint). + * "git pull --ff-only" and "git pull --rebase --ff-only" should make + it a no-op to attempt pulling from a remote that is behind us, but + instead the command errored out by saying it was impossible to + fast-forward, which may technically be true, but not a useful thing + to diagnose as an error. This has been corrected. + (merge 361cb52383 jc/fix-pull-ff-only-when-already-up-to-date later to maint). + + * The way Cygwin emulates a unix-domain socket, on top of which the + simple-ipc mechanism is implemented, can race with the program on + the other side that wants to use the socket, and briefly make it + appear as a regular file before lstat(2) starts reporting it as a + socket. We now have a workaround on the side that connects to a + unix domain socket. + * Other code cleanup, docfix, build fix, etc. (merge f188160be9 ab/bundle-remove-verbose-option later to maint). (merge 8c6b4332b4 rs/close-pack-leakfix later to maint).
Quoted 15 lines · Junio C Hamano
"Johannes Schindelin via GitGitGadget" <[email protected]>
Quoted 5 lines · writes:
From: Johannes Schindelin <[email protected]>
Signed-off-by Johannes Schindelin <[email protected]>---
RelNotes: fix a couple of typos for the upcoming releaseThanks. Relative to -rc2, here is what I have today, taking these typofixes, and a few topics for regression fixes.
+ * "git pull --ff-only" and "git pull --rebase --ff-only" should make
Documentation/RelNotes/2.34.0.txt Fixes since v2.33 · line 415
Quoted 5 lines
Documentation/RelNotes/2.34.0.txt +5
-0+ it a no-op to attempt pulling from a remote that is behind us, but + instead the command errored out by saying it was impossible to + fast-forward, which may technically be true, but not a useful thing + to diagnose as an error. This has been corrected. + (merge 361cb52383 jc/fix-pull-ff-only-when-already-up-to-date later to maint).
Is this worth calling out in the release notes? I thought the discussion elsewhere on this list pointed out that this bug did not exist in v2.33 or before after all, but rather that it was a regression that was new to the v2.34 development cycle.
Quoted 11 lines · Elijah Newren
Documentation/RelNotes/2.34.0.txt Fixes since v2.33 · line 415
Quoted 6 lines
+ * "git pull --ff-only" and "git pull --rebase --ff-only" should make
Documentation/RelNotes/2.34.0.txt +5
-0+ it a no-op to attempt pulling from a remote that is behind us, but + instead the command errored out by saying it was impossible to + fast-forward, which may technically be true, but not a useful thing + to diagnose as an error. This has been corrected. + (merge 361cb52383 jc/fix-pull-ff-only-when-already-up-to-date later to maint).Is this worth calling out in the release notes? I thought the discussion elsewhere on this list pointed out that this bug did not exist in v2.33 or before after all, but rather that it was a regression that was new to the v2.34 development cycle.
The fix itself (i.e. "git pull --ff-only --rebase" when faced with new development on the other side) has already been described in an earlier entry (the third one in "Fixes since v2.33" section) and is in both 2.33.1 and 2.34.0-rc2. The above entry is about what "git pull -ff-only -rebase" does when the other side lags behind us, which should be and used to be a no-op "already up-to-date" but the earlier fix broke it. It should be in 2.34 final, and if we were to issue 2.33.2 later, it should go there, too.
Quoted 15 lines · Junio C Hamano
Quoted 11 lines · Elijah Newren
Documentation/RelNotes/2.34.0.txt Fixes since v2.33 · line 415
Quoted 6 lines
+ * "git pull --ff-only" and "git pull --rebase --ff-only" should make
Documentation/RelNotes/2.34.0.txt +5
-0+ it a no-op to attempt pulling from a remote that is behind us, but + instead the command errored out by saying it was impossible to + fast-forward, which may technically be true, but not a useful thing + to diagnose as an error. This has been corrected. + (merge 361cb52383 jc/fix-pull-ff-only-when-already-up-to-date later to maint).Is this worth calling out in the release notes? I thought the discussion elsewhere on this list pointed out that this bug did not exist in v2.33 or before after all, but rather that it was a regression that was new to the v2.34 development cycle.
Quoted 8 lines
The fix itself (i.e. "git pull --ff-only --rebase" when faced with new development on the other side) has already been described in an earlier entry (the third one in "Fixes since v2.33" section) and is in both 2.33.1 and 2.34.0-rc2. The above entry is about what "git pull -ff-only -rebase" does when the other side lags behind us, which should be and used to be a no-op "already up-to-date" but the earlier fix broke it. It should be in 2.34 final, and if we were to issue 2.33.2 later, it should go there, too.
Ah, I missed that it was in 2.33.1. Thanks, and sorry for the noise.
Quoted 25 lines · Elijah Newren
Quoted 15 lines · Junio C Hamano
Quoted 11 lines · Elijah Newren
Documentation/RelNotes/2.34.0.txt Fixes since v2.33 · line 415
Quoted 6 lines
+ * "git pull --ff-only" and "git pull --rebase --ff-only" should make
Documentation/RelNotes/2.34.0.txt +5
-0+ it a no-op to attempt pulling from a remote that is behind us, but + instead the command errored out by saying it was impossible to + fast-forward, which may technically be true, but not a useful thing + to diagnose as an error. This has been corrected. + (merge 361cb52383 jc/fix-pull-ff-only-when-already-up-to-date later to maint).Is this worth calling out in the release notes? I thought the discussion elsewhere on this list pointed out that this bug did not exist in v2.33 or before after all, but rather that it was a regression that was new to the v2.34 development cycle.
Quoted 8 lines
The fix itself (i.e. "git pull --ff-only --rebase" when faced with new development on the other side) has already been described in an earlier entry (the third one in "Fixes since v2.33" section) and is in both 2.33.1 and 2.34.0-rc2. The above entry is about what "git pull -ff-only -rebase" does when the other side lags behind us, which should be and used to be a no-op "already up-to-date" but the earlier fix broke it. It should be in 2.34 final, and if we were to issue 2.33.2 later, it should go there, too.
Quoted 1 line
Ah, I missed that it was in 2.33.1. Thanks, and sorry for the noise.
No, careful reading is very much appreciated.