From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Schindelin Subject: Re: [PATCH 16/18] fsck: support demoting errors to warnings Date: Tue, 23 Dec 2014 10:50:50 +0100 (CET) Message-ID: References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: git@vger.kernel.org To: Junio C Hamano X-From: git-owner@vger.kernel.org Tue Dec 23 10:51:04 2014 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 1Y3M7I-0007KE-GA for gcvg-git-2@plane.gmane.org; Tue, 23 Dec 2014 10:51:00 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752026AbaLWJu4 (ORCPT ); Tue, 23 Dec 2014 04:50:56 -0500 Received: from mout.gmx.net ([212.227.15.18]:52849 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751046AbaLWJuz (ORCPT ); Tue, 23 Dec 2014 04:50:55 -0500 Received: from s15462909.onlinehome-server.info ([87.106.4.80]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lz3rc-1XqJII3ioy-0148kM; Tue, 23 Dec 2014 10:50:50 +0100 X-X-Sender: schindelin@s15462909.onlinehome-server.info In-Reply-To: User-Agent: Alpine 1.00 (DEB 882 2007-12-20) X-Provags-ID: V03:K0:qXcsjEr1LeOLtZgLpl+i/1GOx870n3MPqKTJ1reey3DQfkPUsVP cgHnpLGjBVb+T8XbL2KArcjzk396sghsEWxpNgrhQnqEYPl44paulBh+tzXfOyyPCAIC3Ts iAq3CXrEcms4WEJzNalJuSDuApsG5n18OaztsUMrTL91fKbiQCXUoP5rTze4JsCLFHbZZnA btLHK1li0rDbWo+Zb97Eg== X-UI-Out-Filterresults: notjunk:1; Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Hi Junio, On Mon, 22 Dec 2014, Junio C Hamano wrote: > Johannes Schindelin writes: > > > On Mon, 22 Dec 2014, Junio C Hamano wrote: > > > >> Johannes Schindelin writes: > >> > >> > Of course you can say that! ;-) The problem these ugly messages try to > >> > solve is to give the user a hint which setting to change if they want to > >> > override the default behavior, though... > >> > >> Ahh, OK, then dashed form would not work as a configuration variable > >> names, so missingTaggerEntry would be the only usable option. > > > > Except that cunning me has made it so that both missing-tagger-entry *and* > > missingTaggerEntry work... > > Then the missing-tagger-entry side needs to be dropped. The naming > does not conform to the way how we name our officially supported > configuration variables. But it does conform with the way we do our command-line parameters, and it would actually cause *more* work (and more complicated code) to have two separate parsers, or even to force the parser to accept only one way to specify settings... Should I really introduce more complexity just to disallow non-camelCased config variables? Ciao, Dscho