Re: [PATCH 0/3] Reject non-ff pulls by default

[John Keeping <john@keeping.me.uk>]

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.