From: Phillip Wood Date: Mon, 12 Jul 2021 17:54:34 GMT Subject: Re: [PATCH] pull: abort if --ff-only is given and fast-forwarding is impossible Message-ID: In-Reply-To: On 12/07/2021 18:08, Junio C Hamano wrote: > Phillip Wood 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