From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: [PATCH 0/3] Reject non-ff pulls by default Date: Mon, 9 Sep 2013 15:52:31 -0400 Message-ID: <20130909195231.GA14021@sigill.intra.peff.net> References: <20130904092527.GB22348@sigill.intra.peff.net> <20130908041805.GB14019@sigill.intra.peff.net> <20130908172605.GF5359@vauxhall.crustytoothpaste.net> <20130909000153.GG5359@vauxhall.crustytoothpaste.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Matthieu Moy , Felipe Contreras , "brian m. carlson" , John Keeping , git@vger.kernel.org, Andreas Krey To: Junio C Hamano X-From: git-owner@vger.kernel.org Mon Sep 09 21:52:38 2013 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VJ7Vm-0005DF-16 for gcvg-git-2@plane.gmane.org; Mon, 09 Sep 2013 21:52:38 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755165Ab3IITwe (ORCPT ); Mon, 9 Sep 2013 15:52:34 -0400 Received: from cloud.peff.net ([50.56.180.127]:57471 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754645Ab3IITwd (ORCPT ); Mon, 9 Sep 2013 15:52:33 -0400 Received: (qmail 22080 invoked by uid 102); 9 Sep 2013 19:52:34 -0000 Received: from c-71-63-4-13.hsd1.va.comcast.net (HELO sigill.intra.peff.net) (71.63.4.13) (smtp-auth username relayok, mechanism cram-md5) by peff.net (qpsmtpd/0.84) with ESMTPA; Mon, 09 Sep 2013 14:52:34 -0500 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Mon, 09 Sep 2013 15:52:31 -0400 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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). -Peff