Re: fc/pull-merge-rebase, was Re: What's cooking in git.git (Dec 2020, #01; Tue, 8)

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 10, 2020, 18:28 UTC
Message-ID: <xmqqim99wm61.fsf@gitster.c.googlers.com>
In-Reply-To: <20201210152715.GQ52960@mit.edu>

"Theodore Y. Ts'o" <tytso@mit.edu> writes:

Show 10 quoted lines

> On Wed, Dec 09, 2020 at 01:28:48PM -0800, Junio C Hamano wrote:
>> 
>> A spot check: do you have pull.rebase set to anything in your
>> config?
>
> FWIW, I haven't set pull.rebase to anything, but what I have done is
> to simply added --ff-only or --rebase to my "git pull" commands.  I
> type fast, though, so it's not that a big deal, and I like the fact
> that the warning is making me explicitly express what it is that I
> want to have happen.

OK, so I would tone down my optimism that the loud warning we have been issuing for a long time would be sufficient---the switching of the default would break people like you.

> It's also true that very often, I end up running "git fetch", then
> look at what I got pulled down, and only then run either "git merge"
> or "git merge --ff-only" or "git rebase" explicitly.

That is very understandable.

"git pull", which is "git fetch" followed by some way to reconcile two histories, does not have to be the only way to interact with histories from other people.

It however doesn't give useful input to help us answer the questions Johannes raised: is it sensible to force users to tell "git pull" if they want to merge or to rebase explicitly, instead of defaulting to merge like we currently do? how much damage are we causing to existing users who expect the command to work the way it currently does?

Thanks.