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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 15, 2021, 20:17 UTC
Message-ID: <xmqqlf67s560.fsf@gitster.g>
In-Reply-To: <CABPp-BExWMSFr7CQskjKVhr5fiWCnxoaN_RaJ2Yir+36aiyBjQ@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 11 quoted lines

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