Thread (8 messages) 8 messages, 5 authors, 2016-06-15

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

From: Richard Hansen <hidden>
Date: 2016-06-15 22:58:42

On 2013-09-09 16:44, Jeff King wrote:
On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help