2.24 release note fixups

[newren]

A couple minor fixes to the 2.24 release notes. I split into two trivial commits just in case folks don't like the second (perhaps some wording about no current plans to remove filter-branch were intended?)

[newren]

/submit

[gitgitgadget]

Submitted as pull.440.git.1572466878.gitgitgadget@gmail.com

WARNING: newren has no public email address set on GitHub

[gitgitgadget]

On the Git mailing list, Taylor Blau wrote (reply to this):

Hi Elijah,

On Wed, Oct 30, 2019 at 08:21:17PM +0000, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
>
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>  Documentation/RelNotes/2.24.0.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/RelNotes/2.24.0.txt b/Documentation/RelNotes/2.24.0.txt
> index b7083cd6b2..26e018078d 100644
> --- a/Documentation/RelNotes/2.24.0.txt
> +++ b/Documentation/RelNotes/2.24.0.txt
> @@ -316,7 +316,7 @@ Fixes since v2.23
>     to access the worktree correctly, which has been corrected.
>     (merge dfd557c978 js/stash-apply-in-secondary-worktree later to maint).
>
> - * The merge-recursive machiery is one of the most complex parts of
> + * The merge-recursive machinery is one of the most complex parts of
>     the system that accumulated cruft over time.  This large series
>     cleans up the implementation quite a bit.
>     (merge b657047719 en/merge-recursive-cleanup later to maint).
> --
> gitgitgadget

Thanks, I hadn't noticed this when I read through the release notes
myself. This looks obviously good to me.

Thanks,
Taylor

[gitgitgadget]

On the Git mailing list, Taylor Blau wrote (reply to this):

On Wed, Oct 30, 2019 at 08:21:18PM +0000, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
>
> As per Wikipedia, "In current technical usage, for one to state that a
> feature is deprecated is merely a recommendation against using it."  It
> is thus contradictory to claim that something is not "officially
> deprecated" and then to immediately state that we are both discouraging
> its use and pointing people elsewhere.
>
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>  Documentation/RelNotes/2.24.0.txt | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/RelNotes/2.24.0.txt b/Documentation/RelNotes/2.24.0.txt
> index 26e018078d..bde154124c 100644
> --- a/Documentation/RelNotes/2.24.0.txt
> +++ b/Documentation/RelNotes/2.24.0.txt
> @@ -6,10 +6,9 @@ Updates since v2.23
>
>  Backward compatibility note
>
> - * Although it is not officially deprecated, "filter-branch" is
> -   showing its age and alternatives are available.  From this release,
> -   we started to discourage its uses and hint people about
> -   filter-repo.
> + * "filter-branch" is showing its age and alternatives are available.
> +   From this release, we started to discourage its use and hint
> +   people about filter-repo.

I suspect that this change was motivated by our off-list correspondence,
where I struggled to phrase a section about this in GitHub's release
highlights.

I think that I'm mostly reflecting what Elijah has already said himself
in another thread, but this change makes sense to me. I think that we
have effectively deprecated 'git-filter-branch'. If we're printing
warnings when it is called, and recommended that users refer to
'git-filter-repo' instead, I think that we might as well call it
deprecated.

But, if that phrase is too heavy-handed for 2.24, I think that this
patch makes a lot of sense. It's--as Elijah notes--confusing to say that
we recommend against using a tool but haven't 'officially' deprecated
it. This works nicely around that issue by not using the phrase
'deprecated' at all, and instead being clear about what the state of
'git filter-branch' is.

>  UI, Workflows & Features
>
> --
> gitgitgadget

Looks good to me.

Thanks,
Taylor

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

Taylor Blau <me@ttaylorr.com> writes:

> ... It's--as Elijah notes--confusing to say that
> we recommend against using a tool but haven't 'officially' deprecated
> it. This works nicely around that issue by not using the phrase
> 'deprecated' at all, and instead being clear about what the state of
> 'git filter-branch' is.

Sounds sensible.  Thanks, both.

[gitgitgadget]

On the Git mailing list, Junio C Hamano wrote (reply to this):

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Elijah Newren <newren@gmail.com>
>
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>  Documentation/RelNotes/2.24.0.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/RelNotes/2.24.0.txt b/Documentation/RelNotes/2.24.0.txt
> index b7083cd6b2..26e018078d 100644
> --- a/Documentation/RelNotes/2.24.0.txt
> +++ b/Documentation/RelNotes/2.24.0.txt
> @@ -316,7 +316,7 @@ Fixes since v2.23
>     to access the worktree correctly, which has been corrected.
>     (merge dfd557c978 js/stash-apply-in-secondary-worktree later to maint).
>  
> - * The merge-recursive machiery is one of the most complex parts of
> + * The merge-recursive machinery is one of the most complex parts of
>     the system that accumulated cruft over time.  This large series
>     cleans up the implementation quite a bit.
>     (merge b657047719 en/merge-recursive-cleanup later to maint).

Thanks.

[gitgitgadget]

This branch is now known as master.

[gitgitgadget]

This patch series was integrated into pu via git@55f0c4d.

[gitgitgadget]

This patch series was integrated into next via git@3cbbb1d.

[dscho]

I am fairly certain that this was not only integrated into next but also master, via git@849e436 and git@efd5444, but apparently GitGitGadget failed to pick up on that because the patches were applied directly on top of master, they were not merged.

[newren]

GitGitGadget did pick up on it, but instead of mentioning that it was "merged to master" it instead reported "This branch is now known as master".