| Message ID | pull.1073.git.1636526490570.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | RelNotes: fix a couple of typos for the upcoming release | expand |
"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).
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.
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.
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.
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.
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.