From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl Worth Subject: Re: Two ideas for improving git's user interface Date: Wed, 01 Feb 2006 17:16:18 -0800 Message-ID: <87irrya7bx.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> <7vhd7ibza2.fsf@assigned-by-dhcp.cox.net> <7v8xsu91vf.fsf@assigned-by-dhcp.cox.net> <87lkwupsbr.wl%cworth@cworth.org> <7v1wym4msq.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_Wed_Feb__1_17:16:11_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Cc: git@vger.kernel.org, Nicolas Pitre , Linus Torvalds X-From: git-owner@vger.kernel.org Thu Feb 02 02:17:20 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 1F4T63-00050d-18 for gcvg-git@gmane.org; Thu, 02 Feb 2006 02:17:15 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161049AbWBBBRL (ORCPT ); Wed, 1 Feb 2006 20:17:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161052AbWBBBRK (ORCPT ); Wed, 1 Feb 2006 20:17:10 -0500 Received: from theworths.org ([217.160.253.102]:39874 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1161049AbWBBBRJ (ORCPT ); Wed, 1 Feb 2006 20:17:09 -0500 Received: (qmail 5663 invoked from network); 1 Feb 2006 20:17:08 -0500 Received: from localhost (HELO raht.localdomain) (127.0.0.1) by localhost with SMTP; 1 Feb 2006 20:17:08 -0500 To: Junio C Hamano In-Reply-To: <7v1wym4msq.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_Wed_Feb__1_17:16:11_2006-1 Content-Type: text/plain; charset=US-ASCII On Wed, 01 Feb 2006 16:38:45 -0800, Junio C Hamano wrote: > > I do not think you have to make it sound *that* negative. Sorry about that. I was just trying to emphasize the new-user confusion, and perhaps I went overboard. > It is a useful timesaver to be able to leave > unrelated changes around in the working tree. > > > I don't think it is, (but please let me know if I've missed some > > useful case). > > I think I've already done this a couple of times today. I'm sorry. I didn't succeed in phrasing the question the way I wanted. Yes, it is useful to be able to leave unrelated changes around in the working tree. So in that sense, it is clearly useful to be able to commit something that is different (in a repository-wide sense) than what is in the working tree. The question I was trying to ask is, for a _single file_ is it ever useful to commit contents that differ from the contents of the working directory? Let's call this a "skewed file" in the index. I haven't used git much yet, but I found two cases for when one might end up committing a skewed file: 1) Modification of working directory after git-update-index or git-add. There has been discussion in this thread already that the user can get a confusing commit in this case. 2) git-read-tree -m # without -u The git documentation already advertises that not using -u here leads to confusion. This one looks historical, and it's not obvious to me whether git-read-tree is used in practice without -u. So, in both of those cases the skewed files seem to lead only to confusion. Are there any non-confusing cases where it's useful to be able to commit a skewed file? If not, we should be able to simplify things since a lot of the UI complexity being discussed (-a vs. no -a, path names vs. no path names), hinges on the handling of skewed files. > Your "git diff" is interesting, but I'd rather make them > completely separate command from "git diff". Perhaps "git > ndiff" and "git ncommit", that assumes there is nothing but "git > commit -a" kind of commits. I'd be fine with some other name than "diff" if strictly necessary, but I'm not suggesting something that makes any assumption about "git commit -a" only. What I want is a simple way to take any "git commit" command and be able to examine the diff that it will be committing. My workflow has been to always perform a final review of such a diff while composing the commit message. I'd like to be able to do that with git. And I think this tool would make a very good learning tool for users trying to figure out the various commit operations, (particularly if we end up with different semantics for merge vs. non-merge, -a vs. no -a, path names vs. no path names, etc.). -Carl --pgp-sign-Multipart_Wed_Feb__1_17:16:11_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBD4V1i6JDdNq8qSWgRAlmTAKCh+ikzp8iRilFUAaAjILb0vtoZuwCfeYVP nzA8U3z2sIexahzHmCFAX0A= =+sBQ -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_Feb__1_17:16:11_2006-1--