Re: [PATCH v5 3/3] rebase: add a config option for --rebase-merges

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 13, 2023, 19:46 UTC
Message-ID: <xmqqa60gtox8.fsf@gitster.g>
In-Reply-To: <CAMMLpeTUbG+b89acan-GXGS4H=J7aQupbK8zdxwNg__U_We2dw@mail.gmail.com>

Alex Henrie <alexhenrie24@gmail.com> writes:

Show 14 quoted lines

> What I really don't want is to paint ourselves into a corner. You're
> right that it's unlikely that the default will ever change from
> no-rebase-cousins to rebase-cousins; I was mistaken. However, Glen
> thinks that in the future we might have some kind of
> rebase-evil-merges mode as well, and that that might become the
> default. If we don't let the rebase.rebaseMerges config value control
> the default behavior of --rebase-merges without an argument on the
> command line, we would have to introduce a separate config option for
> the transition, which would be ugly.
>
> More voices would be helpful here. Does anyone else have an opinion on
> how likely it is that the default rebase-merges mode will change in
> the future? Or on whether rebase.rebaseMerges should be allowed to
> affect --rebase-merges in order to facilitate such a change?

Any such "opinion" about the future, or the belief that we can somehow predict one, would be wrong anyway. So I am not sure soliciting more voices to look into crystal balls would help all that much. Having said that...

The default rebase-merges behaviour may be improved, but changing it in a totally backward incompatible way _without_ a carefully prepared transition strategy will be very unlikely, simply because existing end users would not allow us to. I do not offhand know if the configuration variable(s) you propose would serve as a good mechanism to help such transition.

Thanks.