On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:
> > I think that would address the concern I raised, because it does not
> > create a roadblock to new users accomplishing their task. They can
> > ignore the warning, or choose "merge" as the default to shut up the
> > warning (and it is easy to choose that if you are confused, because it
> > is what git is doing by default alongside the warning).
> 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
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.
I wonder if we have sufficient information at the time of the warning to
print out the actual "git rebase" invocation that would rebase as if
they had run "pull --rebase". I think we may have to do a little
refactoring around the base selection from the reflog (IIRC, git-pull
does not even calculate it at all if you are not using --rebase).
It is also depending on "git rebase" throwing away the merge commit we
just created. Which I think should happen always if you have not
configured anything (though perhaps we will eventually support a pull
mode that does "rebase -p", you would not see this warning with that
option anyway). But another option would be to simply tell them:
git reset --keep HEAD^
git pull --rebase [X...]
where "[X...]" is the arguments they gave to rebase in the first place.
That looks a little less friendly, though.
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