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

["Philip Oakley" <philipoakley@iee.org>]

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Sunday, September 08, 2013 7:10 PM
> 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

Not quite always, it's when it won't fast forward

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

Yes, it/Git should stop and wait for instructions...

>                   which may be done with either
> merge or rebase.

Here I would typically rebase onto an adjusted destination, e.g. onto 
pu, or maybe next, rather than master (or vice versa depending on 
expectations). That is its a feature branch that needs to decide what 
it's on top of (well, I need to decide ;-)

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

or 'fail on non-ff' (which may or may not be the users, or Git's 
default, as per the series title ;-)

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