Alex Henrie <alexhenrie24@xxxxxxxxx> writes: > 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.
