Alex Henrie <alexhenrie24@xxxxxxxxx> writes: >> 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] Ah, I didn't consider other options like `git branch --track`. I haven't looked into what is the norm, but I think we should follow it (whatever it is). If other reviewers have a strong idea of what this norm is, I am happy to defer to them. If not, I can look into it given some time. > 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? I am not an expert on this, so perhaps my opinion isn't that important ;) My understanding is that `[no-]rebase-cousins` affects which commits get rebased and onto where, whereas `rebase-evil-merges` would affect how the merge commits are generated (by rebasing the evil or by simply recreating the merges). From that perspective, it seems like yes, the two would be orthogonal. Hm. Maybe this means that we'd be introducing a new option, and that my hunch that we would change the default to `rebase-evil-merges` is more wrong than I expected. Though I guess this doesn't really affects what we do with the CLI options _now_, since the discussion is about what we do about defaults, and what the default is is quite immaterial. > > -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/
