Re: [PATCH 3/3] tests: optionally skip `git rebase -p` tests
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Nov 1, 2018, 17:18 UTC
- Message-ID
- <da1d00b5-8516-6185-60cf-cc7738daa1a3@kdbg.org>
- In-Reply-To
- <xmqqh8h1tjg9.fsf@gitster-ct.c.googlers.com>
Am 01.11.18 um 07:12 schrieb Junio C Hamano:
Show 10 quoted lines
> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> > writes: > >> 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.
Show 9 quoted lines
> 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.
-- Hannes