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

[Richard Hansen <rhansen@bbn.com>]

On 2013-09-09 16:44, Jeff King wrote:
> On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:
>> I think we need to make sure that we give instructions for how to go
>> back if the default hasn't done what you wanted.  Something like this:
>>
>>     Your pull did not fast-forward, so Git has merged '$upstream' into
>>     your branch, which may not be correct for your project.  If you
>>     would rather rebase your changes, run
>>
>>         git rebase
>>
>>     See "pull.mode" in git-config(1) to suppress this message in the
>>     future.
> 
> Yes, that's a good point. I don't know if just "git rebase" is the right
> advice, though; it would depend on whether we were actually pulling from
> the upstream or not.

Another reason 'git rebase' might not be the right advice:  We don't
want to encourage users to flatten intentional merges.  For example:

    $ git checkout master
    $ git merge --no-ff just-finished-feature-branch
    $ git push
     ! [rejected]        master -> master (non-fast-forward)
    $ git pull
    WARNING: Your pull did not fast-forward [...] run git rebase

If 'git rebase' is run here, the commits on just-finished-feature-branch
will be linearized onto @{u}, which is not what the user wants.

Perhaps one could argue that a user that gets into this situation and is
normally comfortable running 'git rebase' is already experienced enough
to know to ignore the advice to run 'git rebase'.

(Sidenote:  Unfortunately there's not an easy way to recover from this
case without adding another merge commit.  But that's a topic for
another thread.)

-Richard