Re: [PATCH 3/5] pull: handle conflicting rebase/merge options via last option wins

Junio C Hamano wrote:

"Elijah Newren via GitGitGadget" [off-list ref] writes:

quoted

--- a/Documentation/config/pull.txt
+++ b/Documentation/config/pull.txt

quoted

 pull.rebase::
 	When true, rebase branches on top of the fetched branch, instead
 	of merging the default branch from the default remote when "git
 	pull" is run. See "branch.<name>.rebase" for setting this on a
-	per-branch basis.
+	per-branch basis.  Incompatible with pull.ff.

Likewise.

I think it technically is OK to say "only ff update is allowed" or
"ff update is allowed when able" while saying pull.rebase=yes.  

 - For those who say ff=only, the actual value of pull.rebase would
   not matter (i.e. the integration immediately finishes by updating
   to what was obtained from the upstream because there is no new
   development on our own on top of theirs to either replay or
   merge).

 - For those who merely allow ff, an update may fast-forward even
   when pull.rebase is set to true (or any non-false value), while
   we'll replay our own development on top of theirs when their
   history is not descendent of ours.

So I do not see need to declare these combinations "incompatible".
But perhaps I am missing some subtle cases?

Doing such a thing would be wrong. As I already explained multiple
times, pull.rebase can be overriden by the command line. When doing
--merge we want to honor pull.ff, when we don't we want to ignore it.

Since both Elijah and Junio have muted me, and they keep making these
mistakes, can anybody else forward this point to them?

Cheers.

-- 
Felipe Contreras