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, 19:58 UTC
Message-ID: <xmqqpmvjs61c.fsf@gitster.g>
In-Reply-To: <CABPp-BExWMSFr7CQskjKVhr5fiWCnxoaN_RaJ2Yir+36aiyBjQ@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 7 quoted lines

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

Show 7 quoted lines

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

Show 6 quoted lines

> 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.