On Mon, Sep 09, 2013 at 04:44:16PM -0400, Jeff King wrote:
> 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
> > 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.
>
> 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).
We can probably do something like:
opts=
if git merge-base --is-ancestor "$orig_head" "$merge_head"
then
opts=$merge_head
else
opts="$orig_head --onto $merge_head"
fi
so that "git rebase $opts" is the right thing. Most users then get the
simple "git rebase $merge_head" variant.
> 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.
Yeah, I think we should keep it simple if possible. In my experience
people are relatively happy to run a single "make things right" command
but less so if there's a sequence of steps to be performed.
--
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