threads / patch / 56866

patchRelNotes: fix a couple of typos for the upcoming release

Subject: [PATCH] RelNotes: fix a couple of typos for the upcoming release

## tl;dr

6 messages between Nov 10, 2021 and Nov 11, 2021. Diffs are folded; open one to read it.

replies: 5people: 3as markdown or json

Johannes Schindelin via GitGitGadget· Nov 10, 2021, 06:41 UTC · lore
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
    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(-)
Show changes to Documentation/RelNotes/2.34.0.txt +2 −2
diff --git a/Documentation/RelNotes/2.34.0.txt b/Documentation/RelNotes/2.34.0.txt
index effab2ea4b2..e9de4d457b5 100644
--- a/Documentation/RelNotes/2.34.0.txt
+++ b/Documentation/RelNotes/2.34.0.txt
@@ -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

-- 
gitgitgadget
Junio C Hamano· Nov 11, 2021, 17:47 UTC · re: Johannes Schindelin via GitGitGadget · lore

Re: [PATCH] RelNotes: fix a couple of typos for the upcoming release

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 5 quoted lines
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>     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.

Show changes to Documentation/RelNotes/2.34.0.txt +20 −7
diff --git a/Documentation/RelNotes/2.34.0.txt b/Documentation/RelNotes/2.34.0.txt
index effab2ea4b..7ba2a8cddc 100644
--- a/Documentation/RelNotes/2.34.0.txt
+++ b/Documentation/RelNotes/2.34.0.txt
@@ -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).
Elijah Newren· Nov 11, 2021, 18:01 UTC · re: Junio C Hamano · lore

Re: [PATCH] RelNotes: fix a couple of typos for the upcoming release

On Thu, Nov 11, 2021 at 9:51 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 13 quoted lines
>
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >     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.
>
Show 6 quoted lines
> + * "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).

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.

Junio C Hamano· Nov 11, 2021, 20:07 UTC · re: Elijah Newren · lore

Re: [PATCH] RelNotes: fix a couple of typos for the upcoming release

Elijah Newren <newren@gmail.com> writes:
Show 11 quoted lines
>> + * "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).
>
> 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.

Elijah Newren· Nov 11, 2021, 20:17 UTC · re: Junio C Hamano · lore

Re: [PATCH] RelNotes: fix a couple of typos for the upcoming release

On Thu, Nov 11, 2021 at 12:07 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 23 quoted lines
>
> Elijah Newren <newren@gmail.com> writes:
>
> >> + * "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).
> >
> > 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.
Ah, I missed that it was in 2.33.1.  Thanks, and sorry for the noise.
Junio C Hamano· Nov 11, 2021, 20:27 UTC · re: Elijah Newren · lore

Re: [PATCH] RelNotes: fix a couple of typos for the upcoming release

Elijah Newren <newren@gmail.com> writes:
Show 26 quoted lines
> On Thu, Nov 11, 2021 at 12:07 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Elijah Newren <newren@gmail.com> writes:
>>
>> >> + * "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).
>> >
>> > 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.
>
> Ah, I missed that it was in 2.33.1.  Thanks, and sorry for the noise.
No, careful reading is very much appreciated.

← back to recent threads