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

From: Richard Hansen <rhansen@bbn.com>
To: Jeff King <peff@peff.net>
Cc: John Keeping <john@keeping.me.uk>,
	Junio C Hamano <gitster@pobox.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	git@vger.kernel.org, Andreas Krey <a.krey@gmx.de>
Subject: Re: [PATCH 0/3] Reject non-ff pulls by default
Date: Mon, 09 Sep 2013 17:48:49 -0400	[thread overview]
Message-ID: <522E4241.1040105@bbn.com> (raw)
In-Reply-To: <20130909204415.GC14536@sigill.intra.peff.net>

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