Re: [PATCH 3/3] tests: optionally skip `git rebase -p` tests
- Date: Thu, 1 Nov 2018 18:18:00 +0100
- From: Johannes Sixt <j6t@xxxxxxxx>
- Subject: Re: [PATCH 3/3] tests: optionally skip `git rebase -p` tests
Am 01.11.18 um 07:12 schrieb Junio C Hamano:
"Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx>
The `--preserve-merges` mode of the `rebase` command is slated to be
deprecated soon, ...
Is everybody on board on this statement? I vaguely recall that some
people wanted to have something different from what rebase-merges
does (e.g. wrt first-parent history), and extending perserve-merges
might be one way to do so.
Maybe you are referring to my proposals from a long time ago. My
first-parent hack did not work very well, and I have changed my
workflow. --preserve-merges is certainly not a feature that *I* would
like to keep.
The important question is whether there are too many users of
preserve-merges who would be hurt when it is removed. It is irrelevant
whether preserve-merges is a good base for extensions because it can
easily be resurrected if the need arises.
I do not mind at all if the way forward were to extend rebase-merges
for any future features. To me, it is preferrable having to deal
with just one codepath than two written in different languages.
I just want to make sure we know everybody is on board the plan that
we will eventually remove preserve-merges, tell those who want to
use it to switch to rebase-merges, and we will extend rebase-merges
when they raise issues with it saying that they cannot do something
preserve-merges would have served them well with rebase-merges.