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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
