From owner-p4-projects@FreeBSD.ORG Wed Jul 30 14:44:04 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id A214E1065677; Wed, 30 Jul 2008 14:44:04 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 662791065673 for ; Wed, 30 Jul 2008 14:44:04 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: from h2o.riss-telecom.ru (h2o.riss-telecom.ru [80.66.66.11]) by mx1.freebsd.org (Postfix) with SMTP id 80A5D8FC13 for ; Wed, 30 Jul 2008 14:44:03 +0000 (UTC) (envelope-from fjoe@samodelkin.net) Received: (qmail 87774 invoked from network); 30 Jul 2008 21:17:22 +0700 Received: from atlas49.myplace.ru (HELO atlas57.myplace.ru) (80.66.68.49) by h2o.riss-telecom.ru with SMTP; 30 Jul 2008 21:17:21 +0700 Received: (qmail 28049 invoked from network); 30 Jul 2008 00:28:29 +0700 Received: from host89-251-107-5.hnet.ru (HELO husky.fjoe.local) (89.251.107.5) by atlas57.myplace.ru with (DHE-RSA-AES256-SHA encrypted) SMTP; 30 Jul 2008 00:28:29 +0700 Message-ID: <488F5344.7060807@samodelkin.net> Date: Wed, 30 Jul 2008 00:28:36 +0700 From: Max Khon User-Agent: Thunderbird 2.0.0.12 (X11/20080326) MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= References: <200807291601.m6TG1FXh039193@repoman.freebsd.org> <488F4B1A.3000207@FreeBSD.org> <488F4EB8.5010308@FreeBSD.org> In-Reply-To: <488F4EB8.5010308@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Kris Kennaway , Perforce Change Reviews Subject: Re: PERFORCE change 146209 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 14:44:04 -0000 Hello! Gábor Kövesdán wrote: >>> http://perforce.freebsd.org/chv.cgi?CH=146209 >>> >>> Change 146209 by gabor@gabor_server on 2008/07/29 16:01:05 >>> >>> - Just handle some command line options as noop. They seem to be >>> rarely used based on the resources describing them. From now on >>> let's concentrate on the really practical features instead of >>> these ones. >> >> I don't think it's a good idea to "implement" options as NOPs unless >> they really are NOPs. This will just cause silent failure and/or >> script misbehaviour, which may be very hard to track down. > I've been also thinking of this, and I'm still a bit unsure. It would be > bad if scripts failed due to this, but it would be also bad if scripts > didn't run because of a e.g. --side-by-side argument, which rarely (or > never?) makes any difference. I've played with the options a bit and a > lot of them made no difference in the output neither with normal diff > nor with context diff nor with unified diff. Maybe the best way to > investigate what are they for would be to dig deeply in the GNU code, > which is a mess. I haven't even found info about them on Google, thus I > don't think they worth the effort. I think that you should not implement options as NOPs unless they are really NOPs too. /fjoe