On 12/07/2021 18:08, Junio C Hamano wrote:
Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
Thanks for revising this patch, I like this approach much better. I do
however have some concerns about the interaction of pull.ff with the
rebase config and command line options. I'd naively expect the
following behavior (where rebase can fast-forward if possible)
pull.ff pull.rebase commandline action
only not false rebase
only not false --no-rebase fast-forward only
* not false --ff-only fast-forward only
only not false --ff merge --ff
only not false --no-ff merge --no-ff
only false fast-forward only
only false --rebase rebase
only false --ff merge --ff
only false --no-ff merge --no-ff
Do you mean by "not false" something other than "true"?
I mean pull.rebase is set to true/interactive/merges/preserve
Are you
trying to capture what should happen when these configuration
options are unspecified as well (and your "not false" is "either set
to true or unspecified")? I ask because the first row does not make
any sense to me. It seems to say
"If pull.ff is set to 'only', pull.rebase is not set to 'false',
and the command line does not say anything, we will rebase".
Yes because if pull.rebase is not false then the user wants to rebase.
I do agree with you that the command line options
--ff-only
--ff (aka "allow ff")
--no-ff
should override pull.ff and
--rebase
--no-rebase (aka "merge")
should override pull.rebase configuration settings and also override
pull.ff set to 'only' (i.e. the user explicitly wants intregration
of the two histories and at that point "I usually just follow along"
which is "pull.ff=only" no longer applies).
I'd assumed --no-rebase just meant "merge respecting pull.ff instead of
rebasing" rather than "merge ignoring pull.ff instead of rebasing"
Best Wishes
Phillip
