Jeff King <peff@xxxxxxxx> writes: > So I like pull.mode in that sense. But it is also weighed against the > fact that we'd still have to support pull.rebase, and we'd still have to > support pull.ff, and explain how those interact with pull.mode (and I > think any new error in this area must be squelched by those existing > variables, or it would be a regression for people who already picked > their default long ago). I agree that if we were starting from scratch, things would have been much simpler; choose among three ways to reconcile histories (merge, rebase, or ff-only), without adding --[no-]rebase, and allow --[no-]ff only when merging (i.e. things like --ff-only --ff, --no-ff --rebase, would be nonsense combinations). The additional complexity of introducing pull.mode is the primary thing I am hesitant to support it, as we have to design and explain how existing knobs interact with newer one. > Using advice.* to squelch the advice would be fine with me, provided it > was _also_ squelched by the existing config options. Meaning "once you choose between rebase or merge, facing a non-ff history would not trigger the advice message"? I think that is already the case with the released versions of Git, and I think that is a good thing to keep. The advice is only for unconfigured folks who did not tell --[no-]rebase from the command line. One bad thing about it in the released versions is that it would trigger even when the history fast-forwards. The latest round of patches in 'seen' squelches the advice when pulling a fast-forward history even for unconfigured folks as we'd just fast-forward without erroring out. > Which I think is where your thinking is ending up. Pretty much.
