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

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> But first let me check if I understand you correctly:  I think you're
> suggesting that
>   * if --ff-only is given along with any --rebase[=*] flags, then we
> silently ignore the --rebase[=*] flags.
>   * if --no-ff is given along with any --rebase flag other than
> --rebase=false, then we silently ignore --no-ff.
>
> Let me ask the same two questions as for the config:  Does it benefit
> the users to allow them to specify both flags?  Does it hurt some
> users, especially if undocumented that one of the flags will be
> ignored?

I see downsides if you make them "incompatible" and cause the
combination to error out, but otherwise no.  I can imagine those who
regularly use pull.rebase=yes in the configuration to say --ff-only
for a single-shot, for example.  We can view it as either (1)
command line --ff-only overriding configured pull.rebase, or (2)
ff-only made the choice of pull.rebase irrelevant---the end result
is the same (as long as you do not say "no, that's incompatible" and
error out).

> I thought this was the biggest hole in my proposal: there is both a
> git merge --no-ff and a git rebase --no-ff, and they avoid
> fast-forwards in different ways with different results.

When you say "git rebase --no-ff upstream", you are telling the
machinery that even if your current work is direct descendant of the
upstream, you want your commits freshly rebuilt.  But in the context
of "pull", you being descendant of the other side is called "already
up to date", not even "fast forward" (the ancestry relationship
between you and the other side is the other way around).  Does the
"rebase --no-ff" even kick in in the context of "pull --no-ff"?