From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Fri, 16 Jul 2021 21:56:52 GMT
Subject: Re: [PATCH 3/5] pull: handle conflicting rebase/merge options via last option wins
Message-ID: <60f200a49dac3_14cb2089b@natae.notmuch>
In-Reply-To: <xmqqwnpqot4m.fsf@gitster.g>

Junio C Hamano wrote:
> Elijah Newren <newren@gmail.com> writes:
> 
> >     <unset>     *        --no-rebase            merge --ff
> >     only        *        --no-rebase            merge --ff[2]
> >     false       *        --no-rebase            merge --no-ff
> >     true        *        --no-rebase            merge --ff
> 
> I think the second one deserves an explanation.  The rationale for
> ignoring --ff-only is because the act of giving an explicit
> "--rebase" or "--no-rebase" from the command line, when the
> configured default is "I expect to have no development on my own
> here, and only want to follow along", is a sign enough that the user
> does not want to follow along in this particular invocation of
> "pull".  And the rationale for the entire thing to become --ff is
> only because between --ff and --no-ff, the former is the default.
> 
> About the second one, I would understand it if it became "merge
> --ff-only", too.  That is more trivially explained.  I however
> suspect that it would be less useful, but that is open to
> discussion.

It would be very hard to explain in the documentation why these are
different:

  git -c pull.ff=only pull --merge
  git pull --ff-only --merge

And this of course will break behavior for people that arely already
relying on pull.ff=only to do --ff-only (as it was its whole purpose).

Not to mention that this isn't even listed in the table:

  git -c pull.ff=only pull

As well as *all* the configurations with no command line arguments.

-- 
Felipe Contreras