From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: [Census] So who uses git? Date: Tue, 31 Jan 2006 23:22:10 -0800 Message-ID: <87vevzpmql.wl%cworth@cworth.org> References: <46a038f90601251810m1086d353ne8c7147edee4962a@mail.gmail.com> <46a038f90601272133o53438987ka6b97c21d0cdf921@mail.gmail.com> <1138446030.9919.112.camel@evo.keithp.com> <7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net> <20060130185822.GA24487@hpsvcnb.fc.hp.com> <7vek2oot7z.fsf@assigned-by-dhcp.cox.net> <7v4q3jlgw2.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_Tue_Jan_31_23:22:04_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: Linus Torvalds , git@vger.kernel.org X-From: git-owner@vger.kernel.org Wed Feb 01 08:23:28 2006 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1F4CKf-0004S0-A5 for gcvg-git@gmane.org; Wed, 01 Feb 2006 08:23:13 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751340AbWBAHXK (ORCPT ); Wed, 1 Feb 2006 02:23:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751387AbWBAHXK (ORCPT ); Wed, 1 Feb 2006 02:23:10 -0500 Received: from mx1.redhat.com ([66.187.233.31]:53898 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S1751340AbWBAHXJ (ORCPT ); Wed, 1 Feb 2006 02:23:09 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k117N148024569; Wed, 1 Feb 2006 02:23:01 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k117N1110194; Wed, 1 Feb 2006 02:23:01 -0500 Received: from raht.localdomain (sebastian-int.corp.redhat.com [172.16.52.221]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k117N0VB020157; Wed, 1 Feb 2006 02:23:00 -0500 To: Junio C Hamano In-Reply-To: <7v4q3jlgw2.fsf@assigned-by-dhcp.cox.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.4 Mule/5.0 (SAKAKI) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: --pgp-sign-Multipart_Tue_Jan_31_23:22:04_2006-1 Content-Type: text/plain; charset=US-ASCII On Tue, 31 Jan 2006 22:42:05 -0800, Junio C Hamano wrote: > > There is no question we do not commit "another-file" and we do > commit changes to the "existing-file" as a whole. What should > we do to "a-new-file", and how do we explain why we do so to > novices? I'll offer a couple of ill-informed comments from a novice's point-of-view if I may. My first exposure to git (about 1 week ago) was "A short git tutorial" [*] I found the discussion of the index, git-update-index, and the subtle distinctions between the various git-diff commands rather intimidating for an initial introduction. After getting to know the system better over the past week, it seems it should be possible to have a class of "novice ready" tools that provide for common use cases and that never require any mention of the index in their documentation. If so, that seems to me a useful goal to work toward and a useful guide in this discussion. > We could make "git commit" without paths to mean the current > "-a" behaviour, which would match CVS behaviour more closely. Again, my novice experience leads me to favor that change. After reading the tutorial, I had the following sequence in mind for committing an edited file: git update-index edited-file git commit which seemed like more pain than strictly necessary. The next day, when I went to the linux.conf.au tutorial and saw Linus use: git commit -a for the same operation it was a breath of fresh air. I was left scratching my head wondering why the -a behavior wasn't the default for "git commit" with no paths. > However, it would make commit after a merge conflict resolution > in a dirty working tree _very_ dangerous -- it may give more > familiar feel to CVS people, but it is not an improvement for > git people at all. I would rather not. I'm still not "git people" I guess. Could you explain what the danger is here? And is it something the tool could detect and prevent? -Carl [*] http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html [* A better initial introduction for me would likely have been "A tutorial introduction to git": http://www.kernel.org/pub/software/scm/git/docs/tutorial.html so a link to the latter from the first paragraph or so of the former might be very helpful. --pgp-sign-Multipart_Tue_Jan_31_23:22:04_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBD4GGi6JDdNq8qSWgRAt1ZAJ41gI7LCrmTMVWMSQpMW2BSXIwXugCeKsRe +dHKg940XOnmyEyV+mFrfA8= =cYXb -----END PGP SIGNATURE----- --pgp-sign-Multipart_Tue_Jan_31_23:22:04_2006-1--