On Thu, Mar 16, 2023 at 11:32 AM Glen Choo <chooglen@xxxxxxxxxx> wrote: > > Alex Henrie <alexhenrie24@xxxxxxxxx> writes: > > >> > In the future, the default rebase-merges mode may change from > >> > no-rebase-cousins to rebase-cousins. > >> > >> I suspect a more likely future would be that the default is to rebase > >> 'evil' merges instead of trying to recreate merge commits, but of > >> course, the important thing is that we promote the default, not what the > >> default will be... > > > > Glen, do you have any more thoughts? At this point, the only thing > > that's keeping me from implementing Phillip's request to make > > --rebase-merges without an argument clobber rebase.rebaseMerges is > > your suspicion that we might need to change the default rebase-merges > > mode in the future, and I assume that we would want to use the > > rebase.rebaseMerges config option to facilitate the transition. > > (Sorry for the late reply) > > Ah, I don't really have more thoughts on the matter. I am fairly > confident that we would _like_ to change the default to rebase 'evil' > merges, but I don't know how likely that will be. > > Perhaps it would help to enumerate the rules to see if it is too > confusing or not? > > The behaviors we can tweak are: > > - Whether to rebase merges or not (true, false, specified mode, or > default) > - What mode to use when rebasing merges (specified mode or default) > > And the sources are either CLI or config, with CLI always overriding > config. > > Should we rebase a merge? > > - If neither CLI or config tells us whether or not to rebase a merge, > default to "don't rebase merges". > - If one of CLI or config tells us whether or not to rebase a merge, > respect it. > - If both CLI or config tell us whether or not to rebase a merge, > respect CLI and ignore config. > > What mode should we use? > > - If neither CLI or config tells us what mode to use, default to > "no-rebase-cousins" (or whatever default we decide). > - If one of CLI or config tells us what mode to use, respect it. > - If both CLI or config tell us what mode to use, respect CLI and ignore > config. > > If users cleanly separate the two concepts, I think it is quite clear. > (I'm not advocating for this approach, but) e.g. if we pretend that each > behavior were configured separately, like: > > --[no-]rebase-merges [--rebase-merges-mode=(rebase-cousins|no-rebase-cousins)] > > I don't think there would be any confusion. (Having --rebase-merges-mode > be a no-op without --rebase-merges is probably even more confusing to > users, plus this would break backwards compatibility, so I don't think > this is a good idea at all.) > > Your doc patch explains the rules pretty clearly, but perhaps it doesn't > explain this mental model clearly enough, hence the confusion. If we > don't find a good way to communicate this (I think it is clear, but > other reviewers seem yet unconvinced), I wouldn't mind taking Phillip's > suggestion to have "--rebase-merges" override > "rebase.rebaseMerges='specific-mode'". I got the impression that everyone, including Phillip,[1] already agrees that the proposed documentation is clear about the interaction between the config option and the command line option. However, it is a little weird when you consider that other flags with optional arguments, like `git branch --track`, unconditionally override their corresponding config options.[2] Let me ask a different but related question: If we add a rebase-evil-merges mode, do you think that would be orthogonal to the rebase-cousins mode? -Alex [1] https://lore.kernel.org/git/7cf19017-518b-245e-aea2-5dee55f88276@xxxxxxxxxxxxx/ [2] https://lore.kernel.org/git/5551d67b-3021-8cfc-53b5-318f223ded6d@xxxxxxxxxxxxx/
