Hi Hannes, On Thu, 2 Sep 2021, Johannes Sixt wrote: > Am 02.09.21 um 16:18 schrieb Johannes Schindelin: > > On Wed, 1 Sep 2021, Junio C Hamano wrote: > >> 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. > > 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
