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

On Mon, Sep 9, 2013 at 3:24 PM, John Keeping [off-list ref] wrote:

On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote:

quoted

On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:

quoted

You are in favor of an _option_ to allow people to forbid a pull in
a non-ff situation, and I think other people are also in
agreement. So perhaps:

 - drop jc/pull-training-wheel and revert its merge from 'next';

 - update Felipe's series with a bit of tweak to make it less
   impactful by demoting error into warning and advice.

would be a good way forward?

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.

And you propose to show that every single time the user does a 'git
pull'' that results in a non-fast-forward merge? Isn't that what 'git
pull --help' is for?

-- 
Felipe Contreras