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=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: Hyphens and hiding core commands Date: Mon, 27 Nov 2006 16:23:31 -0800 Message-ID: <87ac2cwha4.wl%cworth@cworth.org> References: <7vmz6cfsuw.fsf@assigned-by-dhcp.cox.net> <87bqmswm1e.wl%cworth@cworth.org> <7vodqse90q.fsf@assigned-by-dhcp.cox.net> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Mon_Nov_27_16:23:26_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit NNTP-Posting-Date: Tue, 28 Nov 2006 00:24:36 +0000 (UTC) Cc: Nicolas Pitre , git@vger.kernel.org Return-path: Envelope-to: gcvg-git@gmane.org In-Reply-To: <7vodqse90q.fsf@assigned-by-dhcp.cox.net> 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 ciao.gmane.org with esmtp (Exim 4.43) id 1Goqlx-0003CA-DJ for gcvg-git@gmane.org; Tue, 28 Nov 2006 01:24:29 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933622AbWK1AYU (ORCPT ); Mon, 27 Nov 2006 19:24:20 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933627AbWK1AYU (ORCPT ); Mon, 27 Nov 2006 19:24:20 -0500 Received: from mx1.redhat.com ([66.187.233.31]:5575 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S933622AbWK1AYT (ORCPT ); Mon, 27 Nov 2006 19:24:19 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kAS0OEcn017801; Mon, 27 Nov 2006 19:24:14 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kAS0OEaB029994; Mon, 27 Nov 2006 19:24:14 -0500 Received: from raht.cworth.org (sebastian-int.corp.redhat.com [172.16.52.221]) by mail.boston.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kAS0OD4G013387; Mon, 27 Nov 2006 19:24:13 -0500 To: Junio C Hamano Sender: git-owner@vger.kernel.org --pgp-sign-Multipart_Mon_Nov_27_16:23:26_2006-1 Content-Type: text/plain; charset=US-ASCII On Mon, 27 Nov 2006 15:59:17 -0800, Junio C Hamano wrote: > > I tend to disagree. "This is the easiest way to use, even for > beginners" and "this way should be the default for all levels of > users" are quite different. I'll gladly agree that different defaults make sense for different users. Fortunately, we have a config file syntax that allows advanced users to select the defaults they prefer. But, what should be obvious is that the config file is not an option available for reducing the learning curve of git. > Creating a "git cat" and promote that in the Tutorial makes a > lot of sense, but then that can easily be done with aliases ;-). ... > On the other hand, if "cat-file -p" needs to be used often, I think > there is something ELSE that is wrong. Sure. I don't think "cat-file -p" is any big problem. I only mention it because it _is_ mentioned in the git tutorial. So, let's add "git cat" or else find some other way to address what the tutorial is trying to demonstrate there. > I would not mind if you created "commit-easy" (just like curl > library has curl_x_easy), Are you really serious about that? I think that's an awful idea. Interfaces that give longer names to the simpler functionality are really broken. There are plenty of examples of this kind of thing, (XCreateWindow and XCreateSimpleWindow), but their existence in no way justifies this as a good thing. The git commit syntax already suffers from this, ("commit -a" being a longer name than its conceptually more complex cousin, "commit"), so "commit-easy" would only make that problem worse. > but the current way the command works > is more useful once you grok the index. Being able to work in a > slightly dirty tree and commit only the necessary things, and > being able to do so even for a merge commit, is damn convenient. Sure. You don't need to convert me to that idea. I use that mode regularly, (though probably not more often than when committing an index that happens to match my working tree). But my proposal doesn't remove this functionality at all. > Because there is a learning curve involved, an easier way to use > git without worrying about the index was added in the form of > '-a' for beginners. Yes, there is a learning curve. There's the "once you grok the index" stuff you just mentioned. And it's really backwards to have to teach people that the "basic" way to do something is with a command line that looks more complex, ("commit -a"), and that "once you learn more you'll understand what that -a is all about and you'll know when not to use it". I've taught lots of people how to use git like that, and it's really awkward. It would be much easier if learning new concepts and learning new command-line options were correlated. That would allow whole concepts to be dropped from the most basic introductions to git. > People who use index regularly should not > be forced to spend extra keystrokes for the rest of their lives > only because you want to lose '-a' from the tutorial document. You said yourself in the "cat-file -p" case, that can be done with aliases. No extra keystrokes are needed. And many potential users who are evaluating git compared to other systems _do_ currently see something that will cost them extra keystrokes for the rest of their lives. And that is being used as part of the argument against git in some cases. Now, maybe that's not the real reason people are rejecting git, but it sure would be a nice excuse to remove from the potential list of objections. > The tool should be designed for regular users, not for the first > few pages of the tutorial. I'm not proposing eliminating the index or anything here. I really don't see how the default of this one command has any impact at all on the design of git. It's all still there. -Carl --pgp-sign-Multipart_Mon_Nov_27_16:23:26_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFa4GD6JDdNq8qSWgRAupAAJ4iFWN96aksiK92gwuDXNzN1Sle9QCeOV1Q UCR/s8QJcGc7RonqDnpzkjI= =0wf8 -----END PGP SIGNATURE-----