From: "Jeff King" <p...@peff.net>
Sent: Monday, September 09, 2013 9:53 PM
On Mon, Sep 09, 2013 at 10:50:31PM +0200, Matthieu Moy wrote:
John Keeping <j...@keeping.me.uk> writes:
> I think we need to make sure that we give instructions for how to
> back if the default hasn't done what you wanted. Something like
> Your pull did not fast-forward, so Git has merged '$upstream'
> 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
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
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
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
them know before asking them to resolve them all. So perhaps a
message would be needed for that case (to suggest "reset --merge &&
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html