Re: [PATCH 0/3] Reject non-ff pulls by default

From: Junio C Hamano <gitster@pobox.com>
To: Richard Hansen <rhansen@bbn.com>
Cc: Felipe Contreras <felipe.contreras@gmail.com>,
	Philip Oakley <philipoakley@iee.org>,
	John Keeping <john@keeping.me.uk>,
	git@vger.kernel.org, Andreas Krey <a.krey@gmx.de>
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Date: Sun, 08 Sep 2013 11:10:37 -0700	[thread overview]
Message-ID: <xmqqa9jn6v6q.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <522C168B.7050300@bbn.com> (Richard Hansen's message of "Sun, 08 Sep 2013 02:17:47 -0400")

Richard Hansen <rhansen@bbn.com> writes:

> On 2013-09-07 22:41, Felipe Contreras wrote:
>> On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> 
>>> Which can be solved by adding the above "fail" option, and then
>>> renaming them to "pull.integrate" and "branch.<name>.integrate" to
>>> clarify what these variables are about (it is no longer "do you
>>> rebase or not---if you choose not to rebase, by definition you are
>>> going to merge", as there is a third choice to "fail"), while
>>> retaining "pull.rebase" and "branch.<name>.rebase" as a deprecated
>>> synonym.
>> 
>> All these names are completely unintuitive. First of all, why
>> "integrate"? Integrate what to what? And then, why "fail"? Fail on
>> what circumstances? Always?
>> 
>> My proposal that does:
>> 
>>   pull.mode = merge/rebase/merge-ff-only
>> 
>> Is way more intuitive.
>
> +1
>
> What about something like:
>
>     pull.mergeoptions (defaults to --ff-only)
>     pull.rebaseoptions (defaults to empty?  --preserve-merges?)
>     branch.<name>.pull.mergeoptions (defaults to pull.mergeoptions)
>     branch.<name>.pull.rebaseoptions (defaults to pull.rebaseoptions)

As "pull" has two distinct phases "fetch" and "merge/rebase", your
mergeoptions/rebaseoptions is much better than "mode", which does
not tell which phase of "pull" the mode refers to. It is clear that
they apply to the process to integrate the history obtained from
the other side and your own history into one history.

But it does not help Philip's case, if I understand correctly, where
running "git pull" on some branches is always a mistake and the user
wants it to stop at "fetch the history and objects needed to
complete the history from the other side" phase without proceeding
to the "then integrate the history from the other side and the
history of your branch into one" step, which may be done with either
merge or rebase.  Even if we ignore that "always fail, do not do
anything" use case, your two seemingly independent "mergeoptions"
and "rebaseoptions" do not tell us which one is preferred between
merge and rebase.  A single

    pull.<someoption> = rebase | merge [| always-fail]

makes that choice in a clear way, I think.

Regarding the verb "integrate".

We used to explain "pull" is a "fetch" followed by a "merge".  With
more people using "git pull --rebase", the word "merge" used in that
explanation of "pull" stopped being generic enough.  Simplarily the
"upstream branch" of local branch X is "what you fetch and merge to
update the branch X" but that 'merge' can be 'rebase'.  We needed a
verb to call the process of integrate the two histories into one.

"git pull --help" since 153d7265 (pull: change the description to
"integrate" changes, 2013-07-07) uses that verb [*1*].

And that is where the name of the single configuration to pick how
to integrate the history obtained by the first phase of "pull" came
from.

[Footnote]

*1* I suspect that there may still be places in the documentation
that have not been updated since the days back when the only valid
way to integrate two lines of histories was to merge, and updating
them may be a low-hanging fruit. Hint, hint.