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

Hi Hannes,

On Thu, 2 Sep 2021, Johannes Sixt wrote:

Am 02.09.21 um 16:18 schrieb Johannes Schindelin:

quoted

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

quoted

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.

I think that I managed to address whatever concerns there were about the
`--rebase-merges` backend in the meantime.

That was either my suggestion/desire to make no-rebase-cousins the
default. That has been settled.

Or my wish not to redo the merge, but to replay the first-parent
difference. The idea never got traction, and I've long since abandoned
my implementation of it.

Thank you for clarifying.

Yes, I remember how that idea came up, and I even tried that strategy for
a couple of merging rebases of Git for Windows' branch thicket. Sadly, it
did not work half as well as I had hoped.

The best idea I had back then still is in want of being implemented: sort
of a "four-way merge". It is basically the same as a three-way merge, but
allows for the pre-images to differ in the context (and yes, this cannot
be represented using the current conflict markers). Definitely not
trivial.

quoted

To be honest, I developed one (minor) concern in the meantime... Should we
maybe try to be nicer to our users and keep handling the
`--preserve-merges` option by explicitly erroring out with the suggestion
to use `--rebase-merges` instead? Not everybody reads release notes, after
all. In fact, it is my experience that preciously few users have the time
to even skim release notes...

A valid concern, I would think.

Good. Since you concur with my hunch, I implemented that change.

Thank you for reviewing,
Dscho