From: "Jeff King" <peff@xxxxxxxx>
Sent: Monday, September 09, 2013 9:53 PM
On Mon, Sep 09, 2013 at 10:50:31PM +0200, Matthieu Moy wrote:
John Keeping <john@xxxxxxxxxxxxx> 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.
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html