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:

> Let me ask two questions:
>
> 1. When is it beneficial for users to set both pull.ff and pull.rebase?
> 2. Is it harmful to users for us to allow both to be set when we will
> just ignore one?
>
> I believe the answer to (1) is "never", and the answer to (2) is "yes".

I agree (1) never gives you anything, even though it does not hurt,
and (2) is "meh".

> For the second question in particular, I can think of two example cases:
>
> 2a) Users start with pull.ff=only, perhaps suggested by someone else
> and left in their config for a long time.  When users hit a case that
> can't fast-forward and they either ask for help or find a post on
> stack overflow that suggests setting pull.rebase=true, they do so and
> then get no warning that the setting they just added is being ignored.

Well, overriding "only fast-forward is allowed" with "instead of
merge, you can rebase" is a nonsense suggestion in the first place,
no?  Why does Git suddenly become responsible for such a misguided
suggestion?

> 2b) Perhaps users start with pull.rebase=true (suggested by a
> colleague and forgot about it as they are more of a tester than a
> developer and thus usually only see fast-forwards).  Then at some
> point they need to function as an integrator, and they read the docs
> and determine that pull.ff=false should do what they want to create
> merge commits.

Again, "I want to pee in the snow" is not what you need to act as an
integrator.  I do not see how relevant this example is, either.  You
are just reacting to a wrong suggestion.

> But then they get shocked that they've rebased public
> commits (and perhaps also pushed them out) when they wanted merges.
> Our docs have pretty clearly stated that pull.ff=false and --no-ff
> create merges.

That is something we need to and can fix.  The "pee in the snow
commit can be created by passing --no-ff" was written back when the
designed audiences of "pull" were primarily those who merge (think
of "pull --rebase" as afterthought).  IOW, to the minds of those who
originally wrote --no-ff feature (and its doc), "pull --rebase" was
not in the picture.