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: git and bzr Date: Wed, 29 Nov 2006 16:05:16 -0800 Message-ID: <87bqmpvlxf.wl%cworth@cworth.org> References: <45357CC3.4040507@utoronto.ca> <7vu01ro20b.fsf@assigned-by-dhcp.cox.net> <20061026101038.GA13310@coredump.intra.peff.net> <877iyne4dm.fsf@alplog.fr> <456B7C6A.80104@webdrake.net> <845b6e870611280410j58bdcd99nc05d0f67489293e4@mail.gmail.com> <456C7592.6020700@ableton.com> <456C9DFF.1040407@onlinehome.de> <456CA981.4010808@onlinehome.de> <456CB197.2030201@onlinehome.de> <456DD76C.4010902@gmx.net> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Wed_Nov_29_16:05:16_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit NNTP-Posting-Date: Thu, 30 Nov 2006 00:06:48 +0000 (UTC) Cc: Marko Macek , git@vger.kernel.org, bazaar-ng@lists.canonical.com Return-path: Envelope-to: gcvg-git@gmane.org In-Reply-To: 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 1GpZRg-0006xp-GF for gcvg-git@gmane.org; Thu, 30 Nov 2006 01:06:32 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967693AbWK3AGM (ORCPT ); Wed, 29 Nov 2006 19:06:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S967692AbWK3AGM (ORCPT ); Wed, 29 Nov 2006 19:06:12 -0500 Received: from mx1.redhat.com ([66.187.233.31]:11243 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S967693AbWK3AGK (ORCPT ); Wed, 29 Nov 2006 19:06:10 -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 kAU061Q9012614; Wed, 29 Nov 2006 19:06:01 -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 kAU05tdq009731; Wed, 29 Nov 2006 19:05:55 -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 kAU05suA031127; Wed, 29 Nov 2006 19:05:54 -0500 To: Linus Torvalds Sender: git-owner@vger.kernel.org --pgp-sign-Multipart_Wed_Nov_29_16:05:16_2006-1 Content-Type: text/plain; charset=US-ASCII On Wed, 29 Nov 2006 12:45:18 -0800 (PST), Linus Torvalds wrote: > > Nothing forces you to change the index. None of the normal operations do > that, for example, and you really have to _explicitly_ ask git to update > the index for you. Yes, this is goog. > Why? I mean really.. Why do people mind the index? If you've not done > anything to explicitly update it, and you just write "git commit", it will > tell you exactly which files are dirty, which files are untracked, and > then say "nothing to commit". To start with, that message confuses a lot of new users. "What do you mean there's nothing to commit? I just made changes. And I know you noticed them because you just mentioned the names of the files with the changes to me!". So at the very least, there's some missing guidance as to how to get from the "nothing to commit" stage to actually commit the files the user was trying to commit when they typed "git commit" in the first place. > Maybe we shouldn't even say "use git-update-index to mark for commit", we > should just say "use 'git commit -a' to mark for commit", Yes, I submitted a patch for this. I don't think Junio picked it up because it got him thinking about all the other situations where "git status" doesn't give as much guidance as it should Even with that, the user has to go through the process of: git commit "hmm... why didn't that work" read message git commit -a That's not a _huge_ problem, but it is a little road-bump that a lot of people meet on their first attempt at git. In the thread on the fedora mailing list that prompted my first "user-interface warts" and the patch I mentioned above, the process was worse: git commit "hmm... why didn't that work" read message git update-index git commit "crap... it still didn't work even when I did what it told me to do" Here's the original version of that report: https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html > And the ADVANTAGES of the index are legion. You may not appreciate them > initially, but the disadvantages people talk about really don't exist in > real life, and once you actually start doing merges with conflicts, and > fix things up one file at a time (and perhaps take a break and do > something else before you come back to the rest of the conflicts), the > index saves your sorry ass, and is a _huge_ advantage. In none of these recent threads have I been arguing disadvantages of the index. I'm really just trying to remove one small hurdle that does trip up new users, (see above). I'm not trying to introduce any large conceptual change into how git works, nor even what experienced users do. > So get over your fears, and just ignore it, and things will be fine. Let's help people do exactly that by making the behavior of "git commit -a" be the default for "git commit". -Carl --pgp-sign-Multipart_Wed_Nov_29_16:05:16_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFbiA86JDdNq8qSWgRAiHzAKCQLKzYnPu2VQgdPNiRtCLV5XmDKwCfdZnT VSraOesd3cJAfXFYe+YTojU= =+/Rq -----END PGP SIGNATURE-----