Re: [PATCH 3/3] tests: optionally skip `git rebase -p` tests

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 01.11.18 um 07:12 schrieb Junio C Hamano:
"Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx>
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.

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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux