Jeff King [off-list ref] 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.