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

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

[Johannes Schindelin via GitGitGadget]

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(-)

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

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

[Junio C Hamano]

"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.

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).

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

[Elijah Newren]

On Thu, Nov 11, 2021 at 9:51 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "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.
>

> + * "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.

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

[Junio C Hamano]

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.

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

[Elijah Newren]

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.

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

[Junio C Hamano]

Elijah Newren <newren@gmail.com> writes:

> 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.