Alex Henrie wrote:
On Mon, Jul 12, 2021 at 4:21 AM Phillip Wood [off-list ref] wrote:
quoted
On 11/07/2021 02:26, Alex Henrie wrote:
quoted
The warning about pulling without specifying how to reconcile divergent
branches says that after setting pull.rebase to true, --ff-only can
still be passed on the command line to require a fast-forward. Make that
actually work.
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
I don't think enforcing fast-forward only for rebases makes sense unless
it is given on the command line. If the user gives `--rebase`
`--ff-only` on the command line then we should either error out or take
the last one in which case `pull --rebase --ff-only` would fast-forward
only but `pull --ff-only --rebase` would rebase. We should also decide
what to do when the user has pull.ff set to something other than only
and also has pull.rebase to something other than false set - I'd guess
we'd want to rebase unless there is a merge option on the command line
but I haven't thought about those cases.
I was thinking of --rebase and --ff-only as orthogonal variables.
Nevertheless, we could make --rebase imply --ff, which would be pretty
easy to explain in the documentation for the command-line options.
That way, even though pull.rebase=true with pull.ff=only would enforce
fast-forward-only, the user could easily override it with `git pull
-r`. Would you accept that compromise?
What happens if the user has configured `pull.ff=no`?
--
Felipe Contreras