Re: [PATCH v2 0/7] Drop support for git rebase --preserve-merges

Ævar Arnfjörð Bjarmason [off-list ref] writes:

On Wed, Sep 01 2021, Junio C Hamano wrote:

quoted

"Johannes Schindelin via GitGitGadget" [off-list ref]
writes:

quoted

In 427c3bd28ab (rebase: deprecate --preserve-merges, 2019-03-11) (which was
included in v2.22.0), we officially deprecated the --preserve-merges
backend. Over two years later, it is time to drop that backend, and here is
a patch series that does just that.

A good goal.  There is no remaining use case where (a fictitious and
properly working version of) "--preserve-merges" option cannot be
replaced by "--rebase-merges", is it?  I somehow had a feeling that
the other Johannes (sorry if it weren't you, j6t) had cases that the
former worked better, but perhaps I am mis-remembering things.

Fair enough. To be clear I think this series is fine as-is, we've just
usually done "now that this function is dead, rm it" as part of the
series that makes it dead, so I figured fixups/squashes to change those
parts would be welcome & integrated, likewise Alban Gruin's suggestions
in [off-list ref].

But the git-sh-i18n.sh change and/or his suggestions can be done after
this lands...

I have this funny feeling that the "Fair enough" is thrown at a
comment that you didn't intend to ;-)

On Tue, Sep 07 2021, Junio C Hamano wrote:

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

On Wed, Sep 01 2021, Junio C Hamano wrote:

quoted

"Johannes Schindelin via GitGitGadget" [off-list ref]
writes:

quoted

In 427c3bd28ab (rebase: deprecate --preserve-merges, 2019-03-11) (which was
included in v2.22.0), we officially deprecated the --preserve-merges
backend. Over two years later, it is time to drop that backend, and here is
a patch series that does just that.

A good goal.  There is no remaining use case where (a fictitious and
properly working version of) "--preserve-merges" option cannot be
replaced by "--rebase-merges", is it?  I somehow had a feeling that
the other Johannes (sorry if it weren't you, j6t) had cases that the
former worked better, but perhaps I am mis-remembering things.

Fair enough. To be clear I think this series is fine as-is, we've just
usually done "now that this function is dead, rm it" as part of the
series that makes it dead, so I figured fixups/squashes to change those
parts would be welcome & integrated, likewise Alban Gruin's suggestions
in [off-list ref].

But the git-sh-i18n.sh change and/or his suggestions can be done after
this lands...

I have this funny feeling that the "Fair enough" is thrown at a
comment that you didn't intend to ;-)

I think I meant to reply to
https://lore.kernel.org/git/xmqqlf4aejko.fsf@gitster.g/; I don't know
how I got them mixed up, sorry about that.