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

From: Richard Hansen <rhansen@bbn.com>
Date: Sep 9, 2013, 21:48 UTC
Message-ID: <522E4241.1040105@bbn.com>
In-Reply-To: <20130909204415.GC14536@sigill.intra.peff.net>

On 2013-09-09 16:44, Jeff King wrote:

Show 16 quoted lines

> 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