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

Junio C Hamano wrote:

Phillip Wood [off-list ref] writes:

quoted

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".

No, pull.rebase can have values other than true, like "merges".

  git -c pull.ff=only -c pull.rebase=merges pull

This should rebase because pull.ff=only is meant only for --merge.

I do agree with you that the command line options

    --ff-only
    --ff (aka "allow ff")
    --no-ff

should override pull.ff and

Yes.

    --rebase
    --no-rebase (aka "merge")

should override pull.rebase configuration settings

Yes.

and also override pull.ff set to 'only'

No.

pull.ff=only is specifically set for when the user wants to do a merge,
*not* a rebase.

  git -c pull.ff=only pull # fast-forward merge
  git -c pull.ff=only pull --rebase # rebase
  git -c pull.ff=only pull --no-rebase # fast-forward merge

Whether the merge is implied becuse it's the default, or the user has
explicitely specified it with --no-rebase (should be --merge) does not
matter.

(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).

Nowhere in the description of pull.ff does it say that --no-rebase turns
off pull.ff=only.

pull.ff::
	By default, Git does not create an extra merge commit when merging
	a commit that is a descendant of the current commit. Instead, the
	tip of the current branch is fast-forwarded. When set to `false`,
	this variable tells Git to create an extra merge commit in such
	a case (equivalent to giving the `--no-ff` option from the command
	line). When set to `only`, only such fast-forward merges are
	allowed (equivalent to giving the `--ff-only` option from the
	command line). This setting overrides `merge.ff` when pulling.

That would be a pretty convoluted semantic change.

And BTW, why would these four produce different results?

  git -c pull.ff=only -c pull.rebase=false pull
  git -c pull.ff=only pull --no-rebase
  git -c pull.rebase=false pull --ff-only
  git pull --ff-only --no-rebase

-- 
Felipe Contreras