On Mon, Sep 09, 2013 at 06:02:35PM -0500, Felipe Contreras wrote: > On Mon, Sep 9, 2013 at 3:24 PM, John Keeping <john@xxxxxxxxxxxxx> wrote: > > On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote: > >> On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote: > >> > >> > 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? Only if the user has not given an explicit mode (either on the command line or in their config) and possibly if an advice.pullNonFF variable is not set to false. I think that matches what Git does elsewhere. git-pull(1) provides quite a lot more information that I think a new Git user would be comfortable with. There certainly is not a quick way to find out how to fix this error and I don't think it makes sense to add one because we'll still be presenting the user with all of the other content and they won't have any way to know what they can safely ignore and what they have to read and understand. -- 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