From: "Jeff King" <>
Sent: Monday, September 09, 2013 9:53 PM
On Mon, Sep 09, 2013 at 10:50:31PM +0200, Matthieu Moy wrote:

John Keeping <> writes:

> 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.

Sounds good to me. One option is to display the warning on the
command-line, and another option is to show it in COMMIT_EDITMSG (since
we now default to showing it even for non-conflicted merges).

I hadn't though of that, but showing it in COMMIT_EDITMSG is a great
moment, because you are notifying the user _before_ they create a merge
commit. So the backout/switch procedure is "cancel this by giving an
empty message, then re-run git pull --rebase".

On the other hand, if we run into conflicts, you'd probably want to let them know before asking them to resolve them all. So perhaps a separate message would be needed for that case (to suggest "reset --merge && git
pull --rebase").

In fact this [running into conflicts unexpectedly] is usually my use case, which I mis-described as a no-ff in an earlier reply.

Usually I'd want a clean rebase before submitting patches, but I can see other uses cases where there is a desire that branches show where they started so rebase wouldn't be appropriate.

It should not be necessary to give prescriptions about how to backout of a difficult corner, rather give details about how to go forward after stopping safely and early. The urge to press on (various proposals) may not be the right thing.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to