Thread (9 messages) flat view 9 messages, 5 authors, 2021-07-12

Re: [PATCH] pull: abort if --ff-only is given and fast-forwarding is impossible

From: Junio C Hamano <hidden>
Date: 2021-07-12 17:08:15

Phillip Wood [off-list ref] 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"?  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".

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).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help