From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.176.0/21 X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 From: Carl Worth Subject: Re: [RFC] Two conceptually distinct commit commands Date: Wed, 06 Dec 2006 08:14:31 -0800 Message-ID: <873b7t0zo8.wl%cworth@cworth.org> References: <87d56z32e1.wl%cworth@cworth.org> <7vejrdbzdb.fsf@assigned-by-dhcp.cox.net> <874ps91v79.wl%cworth@cworth.org> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Wed_Dec__6_08:14:24_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit NNTP-Posting-Date: Wed, 6 Dec 2006 16:15:46 +0000 (UTC) Cc: git@vger.kernel.org Return-path: Envelope-to: gcvg-git@gmane.org In-Reply-To: <874ps91v79.wl%cworth@cworth.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.4 Mule/5.0 (SAKAKI) Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: Received: from vger.kernel.org ([209.132.176.167]) by dough.gmane.org with esmtp (Exim 4.50) id 1GrzQq-0002XC-Qd for gcvg-git@gmane.org; Wed, 06 Dec 2006 17:15:41 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936376AbWLFQPO (ORCPT ); Wed, 6 Dec 2006 11:15:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S936372AbWLFQPN (ORCPT ); Wed, 6 Dec 2006 11:15:13 -0500 Received: from cworth.org ([217.160.249.188]:43648 "EHLO theworths.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S936333AbWLFQPL (ORCPT ); Wed, 6 Dec 2006 11:15:11 -0500 Received: (qmail 22023 invoked from network); 6 Dec 2006 11:15:09 -0500 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 6 Dec 2006 11:15:09 -0500 To: Junio C Hamano Sender: git-owner@vger.kernel.org --pgp-sign-Multipart_Wed_Dec__6_08:14:24_2006-1 Content-Type: text/plain; charset=US-ASCII On Tue, 05 Dec 2006 20:53:30 -0800, Carl Worth wrote: > On Tue, 05 Dec 2006 17:13:20 -0800, Junio C Hamano wrote: > 2. Avoiding a change of semantics triggered by merely applying > pathname arguments without any command-line option or > alternate command name. By the way, the original command-line convention I used in the proposal was that the omission of an optional argument should be equivalent to supplying some default argument. Here's another convention that is also useful to examine: Adding path-name arguments limits the behavior of the command, (and does not otherwise change the semantics). I don't know that this is as universal a convention outside of git, but it's quite strong within git. The path name limiting exists in deep parts of the machinery and allows for things like: git log -- paths... # path-limited version of "git log" git diff -- paths... # path-limited version of "git diff" etc. It's interesting to look at how the various commit commands fit (or do not fit) this convention: git commit paths... git commit --only paths... This command cannot be explained in terms of the semantics of "git commit" (without command-line options). This command _can_ be explained as a path-limited version of "git commit -a". git commit --include paths... This command does something _extra_ to the given paths before executing the equivalent of "git commit". I think this is a fairly unique violation of the path-limiting convention. The proposal I made with commit-working-tree-content and commit-index-content consistently follow the path-limiting convention. I think consistency of command-line conventions like this are important for making the tool usable. And there have been notable improvements to consistency of convention in git recently, (for example, using ..[] in git-format-patch rather than ). -Carl --pgp-sign-Multipart_Wed_Dec__6_08:14:24_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFduxm6JDdNq8qSWgRAkpCAJ9PQTOqTVeQl7eNgRt+S3I0wJ1NbACgm9Ri a/ufOs2XE527H4s3MqpSF+I= =tBiP -----END PGP SIGNATURE-----